/stat@combot

Total messages: 213539

я везде использую Get.It . Сразу в виджете получу сервис апи и отправлю запрос

Не хочу тебя разочаровывать, но GetIt - это просто синглтон, который регистрирует другие синглтоны. Так сказать, глобальный менеджер синглтонов.
О недостатках синглтонов много написано.
В общем, не самый это лучший подход.

Хорошо, мне нужен какой-нибудь курс на каком-нибудь онлайн сервисе, после которого у меня будет красивая картинка на которой будет написано, что я молодец и прошел курс.
Было бы круто узнать что-то полезное и поменять отношение с bloc.
Может кто-то сможет что-то посоветовать ?

Ну ты же всё сам знаешь, и ещё постебаться решил - зачем тогда советов просишь?

Общие фразы. Может крашнуться аппа? Я им подключаю сторы mobx

Читал реквест ?

Я ж там не написал, что мне нужен мега-полный курс. Я говорю, что мне нужен курс с сертом.

нет

И если уж выкидывать деньги, то было бы круто найти что-то полезное .

вот и я не пойму, что плохого. Я использую его по назначению) Мне надо иметь один объект апи сервис-провайдера делать запросы

человеку просто мозг жмёт, как недавно выяснилось

подозреваю, что люди иногда не понимают, что виджеты тупо перерисовываются. И где тогда брать необходимые редкие объекты?

Кто-то порекомендует Provider ))) Оно чем то отличается? в плане доставки мне объекта по дереву

Что нет?
Потрудитесь излагать мысли развернуто

GetIt - реализует шаблон ServiceLocaltor.

там немного другая разница. Провайдер тоже управляет жизненным циклом объекта, он собственно для того и нужен, что бы это бойлерплейт сократить. Но основные фишки провайдера какие?
* он встраивается в дерево виджетов
* как и инхерит умеет обновлять стейт который использует watch 
* имеет виджеты билдеры, которые умеют обновляться когда значение в провайдере обновляется

по сути это все сахарок, и сокращалка бойлерплейта, а так инхерит может тоже самое

А что get_it

это типичный IoC контейнер, сервис локатор.
* оторван от конекста, что позволяет в нем регистрировать обмалютно любые зависимости
* имеет более гибкие настройки жизненного цикла (синглтон, фабричный метод, время ижзни равное графу)
* позволяет регистрировать/отменять регистрацию зависмостей на ходу, что иногда полезно, что бы подменять зависмости

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

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

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

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

патерны изучи для начала, менеджер синглтонов

Я читал механизмы правильного старта GetIt . И там прекрасно указывались зависимости