🐘 Ловушка MVI: Как мы превратили ViewModel в God-object
Все мы читали туториалы по MVI (Unidirectional Data Flow). Идея звучит безупречно: у вас есть один Intent (событие от юзера), один Reducer и один State (дата-класс, описывающий весь экран).
На экране авторизации это выглядит как поэзия. Но потом вы приходите на реальный прод.
Вам дают Главный Экран приложения: здесь лента постов, фильтры, баннеры, статус сети, профиль юзера в шапке и плеер в свернутом виде.
И тут начинается MVI-ад:
data class DashboardState(
val isLoading: Boolean = false,
val feed: List<Post> = emptyList(),
val searchQuery: String = "",
val activeFilters: Set<Filter> = emptySet(),
val userProfile: Profile? = null,
val unreadNotificationsCount: Int = 0,
val miniPlayerState: PlayerState = PlayerState.Idle,
// ... и еще 20 полей
)
В чем боль такого подхода?
1. Адские copy(): Пользователь вводит текст в строку поиска. На каждый символ вы делаете _state.value = _state.value.copy(searchQuery = newText). Вы пересоздаете гигантский объект состояния ради одного символа.
2. Конфликты Reducer'ов: Разные корутины грузят профиль, ленту и нотификации. Они начинают драться за актуальный state.value, затирая copy друг друга, если не использовать update { } (а с ним код становится еще более громоздким).
3. God-object ViewModel: Ваша ViewModel разрастается до 1500 строк, потому что она вынуждена имплементить интерфейсы плеера, пагинации, аналитики и поиска.
🛠 Как это чинят Сеньоры? Декомпозиция.
Прагматичный подход гласит: Не будьте догматиками. Один экран НЕ обязан иметь ровно один StateFlow.
Паттерн 1: Раздельные потоки (State Decomposition)
Вместо одного монолитного стейта, разбейте его на логические блоки внутри одной ViewModel:
class DashboardViewModel : ViewModel() {
val searchState: StateFlow<SearchState> = ...
val feedState: StateFlow<FeedState> = ...
val playerState: StateFlow<PlayerState> = ...
}
UI (Compose или Fragment) просто подписывается на нужные куски. Ввод текста в поиск больше не триггерит пересоздание списка постов.
Паттерн 2: Компонентный подход (Множественные ViewModel)
Кто сказал, что на Fragment/Activity может быть только одна ViewModel?
Если у вас на экране есть сложный независимый блок (например, Mini Player), дайте ему свою PlayerViewModel. Пусть она живет в скоупе Activity и отвечает только за плеер. Главный экран будет чище.
MVI это паттерн, а не религия. Умейте дробить стейт, когда он начинает пахнуть.
✍️ @kotlin_lib
