мобильным приложениям, то store и state должны глобальными? Или же на каждую фичу (фича можеть быть как с UI, так и без UI) store и state могут быть свои?
Если я правильно понимаю, то в вэбе не всё приложение state один (со store ещё не до конца понял). По крайней мере со стейтом мне это не очень нравится и хотелось бы, чтобы у каждой фичи свой стейт был. Но это в моём представлении. Вы как к такому относитесь? И как на ваш взгляд подобный подход можно переложить на мобилки?
Пока что мне оч заходит подход в MVICore, где каждая фича имеет свой стейт. И эти фичи можно комбинировать между собой. И при этом всём между фичами налажено общение. Мб, есть минусы в подходе от баду.
B обязательно ли state должен маппится на состояние UI? И может ли фича, у которой UI нет, иметь стейт?
И как при подобных подходах можно шарить бизнес-логику между различными фичами в приложении, если каждая фича находится в своём gradle-модуле?
>B обязательно ли state должен маппится на состояние UI? Таких строгих требований в mvu нет, делайте как вам удобно. В mvicore к такому маппингу сама система компонентов подталкивает.
Классно иметь состояние для фичи, и каждую фичу держать в своём фиче-модуле. А уи реализации для этих фич можно держать в других модулях и очень удобно брать стейт фичи, закидывать в редюсер и на каждый экран рендерить по своему
Использую несколько месяцев MVICore для относительно небольшого приложения. Минусы - куча бойлерплейта (нужно постоянно иметь 2-3 wish, дублировать их в 3-5 effects, еще 3-4 news и пр.), при этом нужно дублировать сущности feature на ui (а это дофига классов). Для небольшого приложения разделение на Actor, Reducer, NewsPublisher излишне (задалбывает разделять на эти 3 класса логику, которую можно написать в 2-3 раза короче, при этом так же читаемо и тестируемо).
Обсуждают сегодня