Кто-Нибудь пытался (успешно делал?) вписать MVI в Clean? Волнует вот какое

дело.

1: Репозиторий довольно чисто, в плане стейтов (не ФП), работает с данными. Просто лезет куда-нибудь в сеть или БД, сохраняет туда сюда, возвращает значения.

2: Интерактор работая с репозиторием(ями) проворачивает это дальше и может иметь свой стейт, который будет уже зависеть от работы репозитория. Вернулись данные с сети? InState.Success. Не вернулись но есть данные с кеша? InState.Cached. Валидация провалилась? InState.ValidationError. И т.д.

3: Экраны в свою очередь имеют свои стейты, базируясь на суммировании стейтов юзкейсов. Вот эта шляпа и выходит как-то жутко. Получается, обрабатывая каждый интерактор - надо вписывать его в общий стейт экрана, что как-то и не убирает той проблемы, которую с помощью MVI призвано решить - разбредание стейта повсюду.

Как вы с этим боролись?

Вариант с "Один экран - онда фича" ниочём, т.к. экран спокойно может содержать несколько фич, которые внешне на экране обрабатываются как-то вместе.

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

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


Плюс такой бонус вопрос к особым любителям MVI, которые его боготворят (тут такие есть ;) ):
Поговаривают, что Feature и является пристанищем бизнес-логики, но эти фичи в стейтах, почти всегда, содержат всякую ерунду вроде "show error", "hide registration button", "selected radio button" и пр., что как-то не очень укладывается в бизнес-логику, а скорее относится к отображению. Считаете это окей?)

1. Тут ты прав, репозиторий весьма удачно вписывается в MVI, у него есть свой стейт, но он либо прозрачен (это кеш) либо не изменяется по ходу работы приложения (base_url и другие настройки) 2.3. то, что презентер или вьюмодель имеет свой стейт, а интеракторы - свой, как раз таки и нужно искоренить. MVI/TEA без единого стейта фичи и чистых редьюсеров - всего лишь слегка бойлерплейтный MV* паттерн. Если хочется соблюдать тру клин, то храни в стейте бизнесовые модели, а вьюмодели создавай на их основе какой-нибудь фабрикой. В ней и будет "презентационная логика", если угодно. Интеракторы я уже выше предлагал как можно переписать - презентер превратить в медиатор между вью, стейтом, редьюсерами, службами и репозиторием, который связывает это воедино

Не храни данные в интеракторе. Если нужно что то сохранить, то это по сути кеш, и он должен обрабатываться в репе. Для всего остального - фичи/редьюсеры

Да давайте обсудим clean и mvi. Кто как видит трансформацию данных? Я так понял обычно рассматривается 3 слоя, какие нибудь event, update, state или intent result state итд. В стейте получается будут детали отображения как говорилось выше. Получается это не бизнес логика а ui слой. Тогда или редюсеры это ui слой или есть еще один UiState и еще одна сущность которая переводит state в uistate. Можно сделать так что интеракторы содержали репозитории и переводили event в update. Тогда это не чистые функции. И они скрывают детали асинхронной работы. И берут на себя функции всяких postprocessor итд из mvicore. Получается тогда event принадлежит бизнес слою. Или можно сделать еще какой нибудь UiEvent слой. Пока я вижу все так. Reducer берет на себя только подготовку стейта, и он и state это ui слой. Интерактор, event и update это buissness слой. Наверное можно делать несколько цепочек разных usecase и reducer которые изменяют 1 стейт экрана и обновляют его.