И что лучше?

явно не библиотека с сервис локатором)

скоупы, диай контейнер)

Ну нету во Флаттере нормального DI. Не прижилось.

как на это посмотреть. решение есть, но большинство не использует

а кто мешает использовать get_it как DI?

просто смущает сильно его синглетон, сейчас думаю можно ли как-нибудь работать зависимостями, не скрывая их, но при этом и без синглетона

если смущает - не используйте синглтон. В чем проблема?

Стикер

а в чем проблема одного инстанта?

захламление кода и усложнение чтения

а в чем его преимущество?

если брать опять же скоуп + диай контейнер, то... передадим один раз в вверху, а потом снизу будет обращаться Dependencies.of(context).something Dependencies.of(context).somethingElse

так сервис локаторы умеют поддерживать скоупы

там, где Вы создаете эти зависимости просто откройте скоуп, положите туда зависимости, и берите ниже по дереву

Я про то, что используя тот подход, о котором я написала выше мы сохраняем в flutter-овском сервис локаторе (context) лишь одну зависимость, её менеджить максимально просто, когда в getIt... getIt<IDKWTF>() getIt<AnotherIDKWRF>()... трудно, труднее этим управлять.

разница между DI и SL лишь в том, что в DI закрытием всех зависимостей и скоупа занимается VM, а в SL нужно делать это вручную

кхм.. я про основной минус sl

не "трудно", а "не привычно"

так подход сказанный мной проще, а потенциальных минусов нет

потенциальный минус - захламление кода

бесконечная проброска одного и того же аргумента всем и всегда

а getIt с синглетоном, который позволяет получить везде и всегда - ок?

не понял вопроса

понял синглтон это нормально

я не поняла, что вы имели ввиду. какая бесконечная проброска?

передавать GetIt как параметр во все дочерние виджеты

не sl, а di

Это максимально кривой способ — зашивая инстансы напрямую в поля, ты себе обрубаешь возможность подменять реализацию через дженерики.

Для чего это? Для тестов?

Но вот. Тут уже вопрос о профите и очевидном недостатке. С одной стороны нельзя сделать так же легко С другой стороны все зависимости скрыты

И как и говорила выше, потенциальному начинающему программисту.. Все эти удобства, которые не ограничены ничем, могут показаться чем-то, что может использоваться везде. В качестве итога получаем ошибку связанную с пост и пре условиями (и это лишь одна из множества возможных ошибок, которая может возникнуть при использовании сервсис локатора, когда человек не знает)

Тут нужно определить о чём идёт речь "о том как должно быть" или "о том как это делается"

Да, в любом случае я ещё учусь, а с вами обсуждать это полезно, даёте новое флоу для размышления Но опять же Service Locator не очень хороший паттерн (скрытие зависимостей), потенциальному стажеру-джуну может показаться ок использовать его где-то там, где это не нужно... И в этих руках сервис локатор превращается в адское извращение. Сервис локатор такое себе В неправильных руках умножаем на несколько раз

Хранить зависимости в дереве контекста не всегда удобно, потому что дерево ветвится и часто происходит ситуация когда в текущей ветке этих зависимостей нет. Хранить все, в таком, случае глобально может быть относительно ресурсоемко и не нужно

Чел, в это и смысл контекста)))

И не только в контексте флаттера)

Подмена зависимостей в контексте может привести к резкому ребилду и ререндеру всего приложения. Использование сервис локатора поможет этого избежать. Пример - локализация. Смена региона перебилдит все приложение. А если нам нужно заменить один репозиторий или сервис это не очень нужно

Что мешает оверрайднуть у инхеритеда условие на ребилд?

И не все приложение, а только как раз таки КОНТЕКСТНЫЕ зависимые виджеты

Ничего не мешает, это вопрос удобства и вкуса. Я изучал как работают inherited и мне кажется удобным использовать Get.i<T>() нежели dependency.of(context) в большинстве случаев. Да и не все вызовы имеют доступ к контексту

Это делается для понимания что откуда и куда И как можно не иметь доступ к контексту ,когда ты что-то рисуешь исходя из контекста

Ага, и тем самым с сл создавая большую модульную связность, невелируя принципом цикличного графа ну и и далее про хидден зависимости даже не буду начинать Как бы, конечно никто не запрещает, пожалуйста

Вызовы функций верхнего уровня части библиотек, например firebase_messaging, не имеют доступа к контексту

И зачем тебе здесь контекст?

Но насчёт того чтобы использовать гетит Это нужно чтобы проект в помойку не превращался * когда работаешь не один

Доступ к навигации при обработке информации из пуш уведомления, к примеру

BloC и тот же MobX с хранением текущей подписки на мессаги не?

Обработка нажатия на пуш происходит в глобальном методе onReceive насколько я помню, и вызовы из фона тоже

1. Для тестов. Вместо Something() подставить MockSomething(). 2. Например, в вебе у тебя одна реализация базы данных, на мобилке другая.

А ещё ты жестко нарушаешь 2-й принцип SOLID. Классы должны быть закрыты для модификации — ты модифицируешь класс каждый раз, когда тебе нужно добавить зависимость.

2-ой принцип не подходит в данном контексте, по-моему. Как-минимум потому что вы делаете тоже самое с мапой. Разницы нет. Этот класс не призван выполнять какие-то операции. Единственное для чего он нужен - работа с зависимости

что следует первой букве S

и это тоже все диаем решить можно

Добавлять записи в мапу, и расширять класс новыми членами — не одно и то же.

Это одно и тоже. В чем разница того, что вы измените в getIt зависимость на какую-нибудь другую (измените логику исполнения сущностей, которые зависят от этой зависимости) что я изменю в контейнере... (измените логику исполнения сущностей, которые зависят от этой зависимости) ?

Я не знаю, как у тебя реализован контейнер, но предполагаю, что там статические не финальные поля. Тогда у тебя не иммутабельный класс.

нет там никаких статических полей

и классы иммутабельные

Кхм

а чем это отличается от: IDKWTF.of(context); AnotherIDSWRF.of(context); ?

что Вы подразумеваете под "менеджерить"? зарегистрировать фабрику? а зачем ее менеджерить?

To manage идём от английского, что оно может означать)

Двумя разными типовыми инстансами и?)

так не надо их никак менеджерить. Их либо объявлять, либо удалять

оптимизировать менеджмент зависимостей - это решать задачу которой нет

Хорошо, нет так нет) И минусов ни у гетита, ни у сервис локатора нет