Вот, обычно работаю с бекэндом, но последние несколько месяцев завязался с приложением Flutter — т.е. фактически это фронт.

И как-то такая хорошая мысля пришла опосля — а было бы здорово иметь единственный глобальный объект, который представляет весь срез данных (текущий) для UI. Т.е. все те данные, которые могут быть видимы пользователем через формы. При этом часть данных может быть не загружена и т.д.

Начал делать стандартным способом через flutter_bloc — много отдельных объектов состояний — для каждой формы свое состояние (а то и несколько для разных частей формы). И глобально они никак не объединены. Якобы считается что это лучше, т.к. божественный объект (God object) это плохо.

Но на самом деле понял как было бы здорово иметь единый объект структурированный, который отображает все UI — все возможные открытые формы (если не открывали или закрыли навсегда — то конкретное поле пустое).

Сначала показалось плохой идеей, вроде там много всего будет. А на самом деле не так много. Вот даже на примере этого сайта — много ли тут форм? Всегда будет одна и только одна форма для отображения списка сообщений (если открываем новую вкладку/окно — то это отдельный объект состояний а новое сообщение пишем в той же вкладке). Всегда будет одна и только одна форма для отображения текущего сообщения.

Т.е. фактически ну пусть даже 25 полей будет в этом классе (дерево список форумов, текущий форум, текущий список сообщений, текущее сообщение и т.д.). 25 это не много. Да даже 50 полей не много, и 100 норм. Но это очень очень редко какая прога будет иметь так много форм разных типов, скорее будет всего 10-15 полей в среднем (естественно — внутри них свои сложные объекты или списки таких объектов).

Плюс этого всего: сразу видна структура данных приложения. И когда одни данные связаны с другими — ты сразу в одном месте это видишь и можешь обновить связанные данные.

Естественно в состоянии нет ничего связанного с UI — ни виджетов ни вспомогательных UI-текстов.

Минус кажущийся — что много данных будет в этом объекте. А на самом деле нет — даже 1 Мб. редко будет (а что такое 1 Мб для современного телефона даже с минимумом 4 Гб. ОЗУ). Данных много не будет, т.к. храните только текущий срез как бы, текущую одну страницу, которую видит пользователь. То что уже не актуально — подчищаете.

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

Применяете ли? Думали ли об этом?

Здравствуйте, Shmj, Вы писали:

S>И как-то такая хорошая мысля пришла опосля — а было бы здорово иметь единственный глобальный объект, который представляет весь срез данных (текущий) для UI. Т.е. все те данные, которые могут быть видимы пользователем через формы. При этом часть данных может быть не загружена и т.д.
S>Начал делать стандартным способом через flutter_bloc — много отдельных объектов состояний — для каждой формы свое состояние (а то и несколько для разных частей формы). И глобально они никак не объединены.

А почему просто не сделал глобальный Flutter Block (AppBlock)?
Вроде как это и есть вполне типичный паттерн использования (типа context в react)

S>Применяете ли? Думали ли об этом?

Вообще полно таких библиотек: Redux, Zustand, MobX, вагон их

Из минусов global state management — global state должно быть неизменяемым, и каждая "операция" должна создавать новое, чтобы это нормально работало.
Это довольно расточительно если операций много. Понятно что все минимизируется (shallow copy например), но если разбить допустим на
несколько отдельных глобальных объектов (flutter block в твоем случае) типа "UserInfo", "Theme" и прочее то это будет эффективнее.

Здравствуйте, Shmj, Вы писали:

S>Вот, обычно работаю с бекэндом, но последние несколько месяцев завязался с приложением Flutter — т.е. фактически это фронт.

S>И как-то такая хорошая мысля пришла опосля — а было бы здорово иметь единственный глобальный о бъект, который представляет весь срез данных (текущий) для UI. Т.е. все те данные, которые могут быть видимы пользователем через формы. При этом часть данных может быть не загружена и т.д.

S>Начал делать стандартным способом через flutter_bloc — много отдельных объектов состояний — для каждой формы свое состояние (а то и несколько для разных частей формы). И глобально они никак не объединены. Якобы считается что это лучше, т.к. божественный объект (God object) это плохо.

S>Но на самом деле понял как было бы здорово иметь единый объект структурированный, который отображает все UI — все возможные открытые формы (если не открывали или закрыли навсегда — то конкретное поле пустое).
Ты придумал mvvm
S>Применяете ли? Думали ли об этом?
Да применял в wpf.

Здравствуйте, bnk, Вы писали:

bnk>А почему просто не сделал глобальный Flutter Block (AppBlock)?
bnk>Вроде как это и есть вполне типичный паттерн использования (типа context в react)

Не принято делать единый глобальный для всего приложения state и bloc, так не предусмотрено. Причина:

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

2. Если оставить все как есть (много разных state и bloc), но дополнительно создать обертку, которая как бы объединяет все state-объекты — то проще не станет. Вам нужно после изменения определенных state не забывать вызвать emit для связанных bloc, иначе ничего не обновится. Как бы смысла нет.

Т.е. изначально не предусмотрен такой сценарий и особо его не натянешь.

bnk>Вообще полно таких библиотек: Redux, Zustand, MobX, вагон их

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

bnk>Из минусов global state management — global state должно быть неизменяемым, и каждая "операция" должна создавать новое, чтобы это нормально работало.

Это плохой вариант. Нужно чтобы как раз было изменяемым — но отслеживаемым. Т.е. изменили поле — все UI, которые его используют — обновились сами.

Здравствуйте, Qulac, Вы писали:

Q>Ты придумал mvvm

Разве? Использовал его в 2012 емнип, более 10 лет назад. Но там рекомендации делать глобальный state вроде не было. State это там — типа модели, моделька могла быть независима для каждой формы.

Здравствуйте, Shmj, Вы писали:

S>Это плохой вариант. Нужно чтобы как раз было изменяемым — но отслеживаемым. Т.е. изменили поле — все UI, которые его используют — обновились сами.

Ну это паттерн такой, global state management называется. С неизменяемым (в смысле, иммутабельным) объектом глобального состояния и диспетчером действий, через которые он изменяется. Т.е. чтобы изменять состояние, ты отправляешь диспетчеру таск на модификацию. Диспетчер модифицирует состояние как запрошено, и оповещает все заинтересованные компоненты об изменении. Компоненты мониотрят это глобальное состояние, точнее, каждый монитори только тот кусочек глобального состояния от которого зависит, поэтому никаких избыточных перерисовок или обновлений не происходит.

Насколько я знаю в flutter block работает так же (в остальных перечисленных это так), но могу ошибаться

Можешь попробовать с жпт или Клодом пообщаться по этим кейвордам, он хорошо объясняет.

Здравствуйте, bnk, Вы писали:

bnk>Ну это паттерн такой, global state management называется. С неизменяемым (в смысле, иммутабельным) объектом глобального состояния и диспетчером действий, через которые он изменяется. Т.е. чтобы изменять состояние, ты отправляешь диспетчеру таск на модификацию. Диспетчер модифицирует состояние как запрошено, и оповещает все заинтересованные компоненты об изменении. Компоненты мониотрят это глобальное состояние, точнее, каждый монитори только тот кусочек глобального состояния от которого зависит, поэтому никаких избыточных перерисовок или обновлений не происходит.

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

bnk>Насколько я знаю в flutter block работает так же (в остальных перечисленных это так), но могу ошибаться

При вызове emit(newState) Flutter будет считать, что состояние полностью изменилось.

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

Здравствуйте, Shmj, Вы писали:

S>Тут вопрос — глобальный объект для состояния всего приложения (сложный объект, с вложенными частями) — один или же много разных для каждой части свой глобальный объект?

bnk>>Насколько я знаю в flutter block работает так же (в остальных перечисленных это так), но могу ошибаться

S>

S>При вызове emit(newState) Flutter будет считать, что состояние полностью изменилось.

S>Т.е. не получится обновить только те части UI, которые связаны с изменившимися полями состояния. Впрочем, есть BlocSelector для ручной фильтрации, но это не автоматом.

Я не специалист во flutter ни разу, просто "мимопроходил", в других это решается через мониторинг состояния (подписки).
Т.е. компонент ре-рендерится только тогда, когда та часть глобального состояния, которая к нему относится, изменилась.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>Ты придумал mvvm

S>Разве? Использовал его в 2012 емнип, более 10 лет назад. Но там рекомендации делать глобальный state вроде не было. State это там — типа модели, моделька могла быть независима для каждой формы.

Но он там обычно есть, например MainFormViewModel.

Здравствуйте, Qulac, Вы писали:

Q>Но он там обычно есть, например MainFormViewModel.

MainFormViewModel — содержит же исключительно то, что относится к главной форме. И не содержит в себе данные дочерних форм.

Кроме того, если подумать — ViewModel вообще не должна содержать данных/полей. Есть Model. Так же есть IValueConverter — если какое-то значение из Model тебе нужно в UI отобразить особым образом (к примеру — статус преобразовать в цвет). Т.е. по сути ViewModel не должно содержать цветов, паттернов для преобразования времени в строку и пр. — это все в конвертеры. Так накой же этот ViewModel вообще нахрен сдался? Получается в нем только постоянные обертки и ничего более. Кроме оберток над полями Model — что там еще может быть (если учесть — что цвета и строки для даты — это утечка абстракции)?

ViewModel как бы одна большая обертка, чтобы над полями Model добавить эти вызовы OnPropertyChanged. Но! Не разумнее ли это отдать на откуп среды/компилятора прямо в Model? Просто не подумали об этом и добавили ручную работу и лишние слои.

Тогда во ViewModel останутся команды эти — но уже и назвать нужно по-другому, т.к. к Model оно отношения не имеет. Это контроллер или диспетчер будет или что-то типа того. В общем, изначальной глупостью было ради вызова OnPropertyChanged создавать отдельную обертку и концепцию.

Здравствуйте, Shmj, Вы писали:

S>Вот, обычно работаю с бекэндом, но последние несколько месяцев завязался с приложением Flutter — т.е. фактически это фронт.

S>И как-то такая хорошая мысля пришла опосля — а было бы здорово иметь единственный глобальный объект, который представляет весь срез данных (текущий) для UI. Т.е. все те данные, которые могут быть видимы пользователем через формы. При этом часть данных может быть не загружена и т.д.

Вы изобрели современный подход — redux и его потомков. До этого такое делалось через разновидность MVC.