А вот настройки приложения это бизнес логика? Например стили/темы/цвета? Ведь

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

С бизнес-логикой на самом деле возникло много путаницы. Если брать DDD, то там больше принято разделять бизнес-логику и логику приложения. Бизнес-логика вообще никак не связана с приложением вообще – это могут быть законы, которые надо учесть в приложении, бизнес-решения. Пример обычно приводят такой – даже если все ваши рабочие процессы выполнять по старинке, без компьютера, то БД никак не поменяется. Логика приложения – это специфичная логика конкретно для вашего приложения. Например, когда сохранить данные в репозиторий (но без реализации самого репозитория), какие данные запросить по API (опять же, без реализации самого клиента). Но в последнее время под БЛ чаще всего подразумевают всю логику, которая не относится к UI и инфрастуктуре. Я обычно советую разделять так (упрощенно): представьте, что вы меняете GUI на CLI. Если логика поменялась – это логика UI, она не должна быть в слое БЛ. Если осталась та же, скорее всего, это БЛ.

Куда лайков завести?) Помню где-то видел разделение на четыре части: По зависимости от конкретного приложения (тех реализации) И ещё там был какой-то параметр и у каждой части было своё название и свой слой

Ну вот по слоям обычно и выделяют: слой БЛ (Business Logic Layer), слой приложения (Application Layer), слой презентации (Presentation Layer) и инфраструктурный слой (Infrastructure Layer).

Это типичный DDD. Адски кошмарная штука. Избегай ее пока можешь.

Я б к таким хорошим ответами, хештеги бы добавлял для быстрого поиска)

да я думаю поиском можно будет найти, если что. Хэштегами кто-нибудь вообще пользуется? )

Я) #iso8601 #reviver #jsonDecode #тесты #Изоляты #о

👍

А что ты думаешь на счёт кешированния виджетов?

делать const – хорошо, хотя бы даже на смысловом уровне – показывает, что этот виджет от текущего контекста не зависит. Плюс оптимизация. Если же именно сохранять инстансы виджетов, то это чаще всего преждевременная и не особо нужная оптимизация. Есть хорошая статья про GC, там прямо написано: It’s not uncommon to see new Flutter developers create references to widgets they know will not change over time, and place them in state so that they won’t be destroyed and rebuilt. Don’t do this. https://medium.com/flutter/flutter-dont-fear-the-garbage-collector-d69b3ff1ca30

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

Во-первых, ребилд != ре-рендер. Во-вторых, ребилдить он будет все равно до первой константы. На практике я как-то не сталкивался с ситуацией, когда такое кэширование приносило бы ощутимую пользу. В рамках одного виджета глубокое под-дерево строить – так себе идея в любом случае, там и так будут вынесены отдельные виджеты, а ребилд нескольких виджетов ничего не изменит. Опять же, если build-метод, как положено, легкая и чистая функция.

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