И всем 150 экранам нужны блоки все?)

 

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

 

ну 150 + запросов, каждые данные получают

 

по каждому запросу Loading Loaded, значит на каждый запрос по блоку

 

У тебя не может быть открыто больше 1 экрана за раз начни с этого ;)

 

Виджет слушает когда он создан

 

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

 

Виджет не существует - не слушает

 

Удаляй лишнее

 

Блок и нужен для того чтобы хранить Стейт

 

Создал видежет - получил Стейт для него

 

Удалил виджет со стека - освободил RAM

 

Не нужно все хранить в памяти

 

я не вкуриваю к чему это)

 

ты же и предлагаешь глобально блок объявить

 

я же хочу блок провайдер вешать на экран, экран повился, блок создался, экран сдох, блок сдох

 

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

 

Не так, блок создаётся до того как появился экран

 

Он при старте приложухи уже есть но пустой

 

ну само собой

 

это если глобально запихать

 

В зависимости от действий в нем что то происходит (бизнес логика) меняются стейты

 

BlocProvider создает блок, в методе билда конкретного виджета

 

Консюмеры реагируют на эти изменения

 

Экземпляр класса чтоли?))

 

Блок уже создан(создан экземпляр класса). Он занял n оперативки. Доступен всему приложению. Например ты для виджета дергаешь какой то его метод : вернуть сортированный список . Не будет создаваться новый экземпляр блока. Вернутся просто новые данные например новый стрим

 

Эта оперативки занята пока живёт виджет который вызвал этот метод или явно не вызвал dispose

 

Ну или чо не понимаю хз)

 

Ну дак если он создается в самом руте - он и живет пока жив рут. Т.е. все время. Даже если нужен паре экранов. Я проблему автора вопроса так понял.

 

Экземпляр класса продолжает существовать и после dispose, вы всего лишь стримы глушите. В вопросе автора, передай его через навигатор, или подними выше

 

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

 

Можно не создавать вложенный навигатор, а просто блок передать при навигации

 

Я тут так и написал

 

Нафига передавать через виджеты непонятно. Если будет pushandreplacement например)

 

С вложенным навигатором появляются некоторые сайд эффекты которые надо хэндлить

 

Бойлерплейт же ?)

 

Я ни к чему не призываю, просто размышления

 

А обрабатывать потом вложенную навигацию не бойлерплейтный?)

 

А ну да)

 

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

 

И избежать DI

 

Callback hell

 

Как там ещё по умному

 

Но тогда он будет висеть в памяти все время работы приложения. Ради двух экранов.

 

Если он будет пустой

 

Тоти памяти не займет

 

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

 

Что блин значит пустой? Стейт будет, логика будет, держать свои зависимости тоже будет.

 

Даже если вы закроете стримы он не будет пустым

 

Стримы просто перейдут в done состояние

 

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

 

Или у вас навигация это дорога в один конец?

 

Смотря какая навигация. Если эти 2 экрана не нужны потом всему приложению - они слушают блок, что то делают потом диспозятся. в чем минусы?

 

Еще раз. Если блок глобальный - то несмотря на то то два этих экрана задиспозятся он все равно продолжит висеть в памяти со всем фаршем.

 

тут подход не понятен - блок это стейт менеджмер - он отдает стейт (и данные) тому кто его слушает

 

Верно

 

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

 

если блок нуден только для 2х экранов из 150 - значит он не нужен. нужно его впилить в какие то существующие

 

Народ, кто использовал yandex mapkit flutter? Не могу найти внятной документации, как добавить маркеры, задать координаты и т.д.

 

Так то блоки наоборот как можно меньшими рекомендуют делать. По несколько на один экран например вполне валидный вариант. Вы утверждаете что их нужно наоборот делать больше?

 

всем привет, есть тут кто работал с подписками в in_app_purchase?

 

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

 

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

 

Суть хорошей архитектуры в том, что нужные вам инстансы живут только в нужном вам месте, идея сделать всё глобальным дабы не мучаться облегчает всё лишь на первый взгляд, и хоть для маленького приложения может ещё пойдет, использовать такие подходы не очень хорошо. Выше вам объясняли почему.

 

Согласен, но блок нужен только тогда , когда он живёт сквозь все приложение

 

Иначе это забивание гвоздей микроскопом)

 

В качестве пятничной дискусси можно прям разложить типовой интернет магазин на блок паттерн ))

 

Не мучаетесь с блоками, используйте ChangeNotifer + Provider????

 

И все будет по фен-шую

 

Категорически не согласен. Скорее наоборот.

 

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

 

а вот прокидывать через навигацию можно попробывать, с nested navigators реально гемморой

 

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

 

Почему же? Там где он не нужен достатчно провайра

 

Смысл блока в том чтобы UI (виджет) знал от чего ему строится . Единое состояние для конкретного экрана

 

Предполагаю это издержки навигатора(

 

Видимо во мнениях не сойдемся.

 

Есть чего нового про Navigator 2.0?

 

Это состояние не обязательно должно быть глобальным

 

В зависимости от стейта мы выводим то или иное или третье

 

Смысл блока в отделении бизнес логики от представления. Это даже в названии паттерна записано. Бизнес логика может быть не то что для экрана, для небольшого кусочка экрана отдельная.

 

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

 

Именно. Ничего не мешает в блоке делать Стейт под конкретный виджет

 

1 блок может брать стейты из другого и так далее

 

А я и не спорю. Я как раз к тому что блок никак не регламентирует что именно он обслуживает. Это вполне может быть цепочка экранов от корзины до завершения покупки например. И с тем же успехом блок который связывает на экране списка товаров только два виджета, корзину и кнопки добавления в корзину. Или и вовсе два блока, один на кнопки добавления в корзину, второй на виджет значка корзины. Работающие с одним репозиторием.

 

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

 

Если вы это глобально сделаете, куча стримов слушающие кучу других стримов, которые в итоге никто не слушает будет не очень хорошо

 

У вас малейшее изменение будет вызывать кучу сайд эффектов которые возможно вообще сейчас не нужны

 

Если уж мы говорим именно про паттерн, как он есть, в нем кроме как sinks for input, streams for output ничего не регламентировано

 

Для этого есть equtable, который позволяет не брать лишнее)

 

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

 

Смотря что хранится в этом экземпляре

 

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

 

Но только это бизнес логик компонент, а не Стейт компонент)

 

Т.е. использовать блок и не использовать стейты?) Какой тогда в нем смысл

 

Отделение бизнес логики от представления. Как и задумывалось авторами.

 

Блин, довольно забавно участвовать в спорах по флаттеру имея в активе только штуки три кодлабы повторенных да четверть прочитанной "Flutter in action"))

 

Это вы у Гугла спросите) но только блок про логику, имеется ввиду что не надо писать вообще все в виджет е, верстка в виджете, логика в отдельном компоненте

 

Архитектура во всем фронте +- одинаковая

 

Если следовать только гуглу мы застрянем на countet_noob_app.dart ;)

 

Но тем не менее

 

У блока есть определение

 

Вот да, я к тому же. Очень забавно. Вроде стек не знакомый практически, но в спорах спокойно можно участвовать имея опыт натива)

 

Если ему не следовать это будет уже не блок

 

Очень размытое

 

Как и у любой архитектуры)

 

Но тем не менее там говорится про бизнес логику) а не про Стейт

 

Вообще мне блок катастрофически не зашёл

 

Причем для любых кейсов

 

Вот пример у нас есть корзина . У нее есть блок . Который имеет абстрактные классы state и event. Мы можем их расширять своими. Например добавили айтем в корзину произошел event который вызовет новый Стейт. Виджет обновит количество товаров

 

Виджет слушает только Стейт

 

И ничего не знает про евент

 

При этом о блоке говорится как о State management pattern

 

Логично ли такой блок покинуть на все приложение?

 

И используется чаще всего именно так

 

В зависимости что такое все приложение, на экране справки он явно не нужен

 

Стейт это результат (именно результат) выполнения бизнес логики. Так то его блок даже хранить не обязан)

 

Зависит от того что за приложение. Если там только корзина и список товаров - да. Если есть другая функциональность на других экранах - нет.

 

Вот. Тут мы подходим к архитектуре

 

А может и нужен, может вы хотите в аппбаре там выводить количество элементов в корзине, слишком абстрактный пример

 

Именно!

 

Нельзя сделать идеальную абстрактную архитектуру

 

Но началось все с конкретного примера где блок нужен 2 экранам из 150. А вы зачем то его глобальным сделать предлагаете

 

Под каждую задачу она будет своя

 

Ну вы же предлагаете идеально глобальные стейты

 

На всё

 

Я предлагаю глобальные стейты только там где они нужны

 

Т.е. 148 экранам которым блок не нужен он на самом деле нужен?

 

Нет. Там в принципе не нужен блок для этих 2х экрвнов

 

Сразу в глобал вынести? Или как?

 

Опять 25. Возвращаемся к тому что блоки должны только все приложение охватывать и никак иначе?

 

Кажется надо просто про solid почитать

 

И все

 

Кстати, может ошибаюсь, но это не так уж давно. Когда впервые про флаттер читал (года полтора назад) - вроде там именно как о стейт менеджмент паттерне не говорилось. Но могу и ошибаться, я тогда чуть почитал да пошел из 1с в натив перекатываться, оставив флаттер надолго.

 

Но solid не работает)) покажите мне solid в проде

 

Махровый легаси

 

Ни разу не видел(

 

Очевидно вы не там работаете

 

Потому что я уже лет не видел что бы в проде не было солида

 

если правильно готовить и без фанатизма то ещё как работает

 

Даже если так, то, что что-то не работает не повод сделать ещё хуже

 

Обычно бывает как - бизнес даёт бабки и сроки а как это реализовано мало кого е)

 

Опять несостыковка двух культур

 

Вы предлагаете укрупнить компоненты и сделать глобальными в контексте всего приложения

 

Находятся подрядчики делают

 

Для вас обычно )

 

Пожалуй) У нас солид даже в 1с частично работал. А там от ооп одни огрызки))

 

Но 1с это фп ) причем 1с я считаю вполне офигенный инструмент для решения бизнес задач здесь исейчас

 

Какое к чертям фп?

 

Процедурщина голимая

 

Просто в моём мире то что тут многие говорят считают полным мракобесьем на которое только самозванцы способны) я какое то время тоже так считал. Теперь просто понимаю что это два разных мира

 

А ведь я даже не работал в Энтерпрайзе, интересно что там происходит

 

Хз, я просто пишу код за бабло, а холивары это так, в пятницу под пиво)

 

Кажется что ты пишешь скорее результат за бабло)

 

Именно

 

Где замыкания? Где функции первого порядка? Где каррирование?

 

За который платят здесь и сейчас

 

Ой началось

 

Ок , перегнул)

 

Ну блин, человек 1с фп назвал. Из меня эта чертова 1с 4 года все соки тянула. Не мог не отреагировать

 

Добавлю в резюме "высокий уровень эмпатии")

 

Фп это чистые функции. Все остальное уже опционально))

 

Ну это как сказать. Впрочем и с чистыми функциями в 1с беда.

 

Но согласись, на 1с развернуть бэк под нужды условного ооо вектор гораздо проще чем писать "имба солид бэк по фен-шую"?

 

Что ты имеешь ввиду фп?

 

1с это скорее уж CMS)

 

В холивары о бизнес пользе вступать не собираюсь. И вообще я только хотел прояснить что 1с к языкам фп относить никак нельзя. Никаким боком.

 

Скорее фреймворк с жирной стандартной библиотекой под цели учета и простеньким ORM. И своим языком.

 

Не, там же можно мышкой накликать себе всякие формы и вот это вот все?

 

Ну так себе. В андроид студио или xcode тоже. Примерно на том же уровне.

 

Мышкой логику не опишешь, только UI

 

Я когда 1с щупал мне казалось что это именно CMS с большими возможностями к кастомищации)

 

Фп это когда ты бесконечно юзаешь функции чтобы получть результат засунуть ее в др функцию и получить результат .

 

Это процедурка

 

А я помню там регистр накоплений мышечкой создаёшь и ничего не работает

 

Процедурное программирование

 

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

 

Там на самом деле все сложнее)

 

Функциональное программирование это скорее про понимание функций как их понимают в математике

 

У тебя нет доступа у бд, ты можешь писать только select запросы и т.п

 

Это в твоём мире)

 

В мире малых ИП там все мышкой делается)

 

[
{
"type": "link",
"text": "https://www.youtube.com/watch?v=Bepwx4j_vvA&feature=emb_logo"
},
" мой видос снова спешит на помощь)"
]

 

Не ну там реально накликать офигенный отчёт в скд мышкой если шо)

 

Который соберет агрегат с неск таблиц

 

А это уже доработки стандартных решений, разработкой одного из которых я в т.ч занимался

 

В малых в нашем мухосранске вообще работают в googledocs и я их не осуждаю)

 

Так, с фп разобрались, надо по блокам дальше спорить)

 

А то офытоп

 

Давайте)

 

На чем мы там остановились?

 

Даже хз. Я лично так и не придумал нормальный способ блок на два экрана расшарить.

 

Из 150

 

Я бы сделал не блоком если он нужен только 2м экранам

 

Тупо провайдер

 

Но опять же неизвестна задача)

 

Опять же, провайдер на все экраны в данном случае расшарит.

 

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

 

Вам или вложенную навигацию делать, или аргументами передавать

 

Пожалуй как то так, да

 

поэтому тут блок и норм) не надо парится кто там что передал

 

DI HELL