s
Виджет с 10 полями, имхо, это уже плохо
Size: a a a
2020 December 09
R
У нас на проекте принято для каждого поля, хоть булеана делать стримбилдер, и мне кажется, что это треш
R
Виджет с 10 полями, имхо, это уже плохо
Ну тут огромная страница с кучей инфы)
R
16, если быть точным
s
И что?
Можно же в композицию поиграть - оно и переиспользуемо будет и вот такие вопросы отпадут
Можно же в композицию поиграть - оно и переиспользуемо будет и вот такие вопросы отпадут
R
Ок, ещё сильнее уточню
R
Есть около 10 виджетов, которые вкомпозированы в родительский контейнер, и есть класс который грузит или вычисляет эти 16 полей
R
Суть не в этом)
R
Проблема в том, что если изменение одного из полей должно повлечь изменение другого виджета, это без костыля в виде stream.add(stream.value) или setState не реализуемо
CI
можно уже шутить про архитектуру?
s
Проблема в том, что если изменение одного из полей должно повлечь изменение другого виджета, это без костыля в виде stream.add(stream.value) или setState не реализуемо
реализуемо, если вы используете bloc/mobx/redux/etc
R
реализуемо, если вы используете bloc/mobx/redux/etc
вот проблема что наш архитектор неправильно понял bloc, а переписать всё уже нереально
s
вот проблема что наш архитектор неправильно понял bloc, а переписать всё уже нереально
ну вы же не по одному полю с сервера получаете?
R
местами по одному) тут около 7 запросов
s
Суть в том, что вы оперируете какими-то моделями (которые, возможно, получаете с сервера). Логично предположить, что если пришло новое значение какой-то модели, то вы перерисуете виджет, с которым эта модель связана.
s
так что в ваши стримы логично было бы не отельные поля кидать, а те самые модели
s
тогда и вопрос отпадает
s
грубо, если пришли новые данные по юзеру на экране профиля, то у вас будет всего один стрим, в котором тот самый юзер приходит в этот экран.
R
Классно, когда флаттер проект начинали делать люди, которые никогда не занимались мобильной разработкой =)
t
рефакторинг займет пару дней