The Elm Architecture в Android проекте: 3 года спустя

Когда не пишешь приложение с нуля, а мигрируешь уже существующее, у тебя связаны руки. Тебе нужно иметь возможность взаимодействовать с любым старым кодом, как бы странно он не был написан. Поэтому решение должно было быть максимально абстрактным и легко расширяемым.

Ещё в марте 2018 RxJava 1 достигла последнего релиза. Создатели фреймворка не собирались далее её поддерживать. Но RxJava была на всех слоях. Типичное приложение того времени состояло из реактивных обёрток над БД и ретрофитом, реактивных обёрток над Вьюхами и заставки Windows XP “Водопровод” из реактивных операторов между ними.

Мигрировать такое большое приложение, как Авто.ру, на другую версию Rx - очень не простая задача, на которую не хватало технического бюджета.

Хотя мне и доверили внедрение новой архитектуры, признаюсь, опыта решения подобных задач было немного. Я толком не знал, как лучше провязать DI, как быть с сохранением стейта. Ну а самое главное - я не мог предугадать направление технического развития проекта. Да, я думал, что мы когда-то будем вынуждены отказаться от RxJava 1, ну или что в Android команде когда-нибудь сделают свой аналог React и заложил эти риски. Но я не мог предсказать, какие технические проблемы будут стоять перед проектом в будущем

TEA, как и любая другая UDF архитектура, очень хочет знать всё про всех и владеть т.н. источником правды - неделимой истиной, постулатом, из которого выводится всё остальное состояние системы, как из пачки аксиом можно вывести всё геометрию. И это хорошо соотносится с веб-приложениями, для которых дизайнилось всё семейство UDF - MVI, Redux, TEA, <ваш arch-name>. Но как бы мы не желали унести всю логику на бекенд, от Android приложения ожидается, что оно при отсутствии интернета не превращается в тыкву. А ещё, что открыв его через 10 минут ты останешься на том же экране с тем же введённым запросом и состоянием. Это значит, что часть стейта нужно хранить не в памяти приложения, a на диске. В Puerh предполагалось что часть стейта будет отправляться эффектом для сохранения на диск, но это раздрабливает стейт и заставляет вас его синхронизировать. Это сложно и этим редко когда есть время заморачиваться.

Я ранее писал о коэффектах - ситуациях, когда, в отличие от эффектов, нужно что-то получить из “грязного внешнего мира”, нежели что-то туда записать. Например, текущую дату для блокировки кнопки распродажи вовремя или случайное число для запроса. В каком-то смысле это всё тоже кусочки “источника правды”. Но моя реализация предполагала что эта “правда” придёт в Msg либо вообще минует бизнес-логику и будет добавлена на стороне эффекта. Несмотря на то, что ситуация довольно редкая, тем не менее хотелось бы иметь для неё консистентное решение и не полагаться ad hoc. Тем более что она перекликается с проблемой выше.

Когда работаешь с TEA, хочется иметь навигацию в виде стейта. Чтобы ты мог посмотреть в стейт любого из предыдущих экранов, подвигать его, как тебе удобно. Я писал такой стейт для частных случаев многоэкранных юзерстори, но сделать обобщенный навигационный фреймворк на основе стейта, интегрируемый с TEA - слишком сложная задача для меня. Тем более, что есть множество решений от коммьюнити, которые хотелось бы переиспользовать, а не выкидывать их из проекта чтобы втащить TEA.

Когда я хочу выделить какую-то общую логику с мессаджами, эффектами и логикой вокруг них - я могу завести “фичу-донора”. Это будет фича, единственное предназначение которой - быть донором логики для других фичей. Из-за того, что я могу заглянуть внутрь стейта фичи-донора, потрогать её эффекты, я могу очень эффективно “допиливать напильником” фичи-доноры под свои нужды. И это очень круто работает, когда это необходимо. Когда же я хочу не вдаваться в подробности, чтобы фича-донор просто “делала своё дело” - это мешает, потому что мне всё равно надо заплатить цену необходимого бойлерплейта за это. Особенно эта цена становится ощутимой, когда пытаешься сделать всё приложение на едином стейте. Обычно экраны на одном уровне навигации между собой слабо связаны, но должны быть донорами для фичи верхнего уровня.

В Puerh нам навязывается иерархичная структура приложения. Это не совсем плохо, ведь есть трейд-офф между жесткой иерархичностью и динамизмом плоской структуры. В иерархии всегда можно найти проблему, спускаясь по дереву сверху вниз. В такой структуре сложнее пропустить Msg или забыть обработать Effect. Однако это всё обрастает бюрократией в виде бесконечных wrapping-ов для передачи данных вверх-вниз, пока не добредёшь до настоящей бизнес-логики.

В Puerh мы в команде долго обсуждали, стоит ли делать EffectHandler иерархичным, где верхнеуровневый EffectHandler определяет, как эффекты передать его “подчинённым” или же плоским, где каждому EffectHandler выдаётся все Effect, а он лишь отбирает нужные. С одной стороны, в иерархичном подходе мы гарантированно обрабатываем все Effects, благодаря exhaustive matching. С другой стороны, плоский подход позволяет писать меньше кода и даёт больше гибкости. Мы остановились на плоском подходе и мне кажется, что это решение позволило больше сэкономить кода, чем бы нанёс пользы exhaustive matching. Ведь проблемы, которые в теории решал иерархический подход, ни разу не всплыли в продакшне.

Хорошей практикой в мире Android приложений сейчас считается выделять компоненты, которые закрывают собой целиком юзер-стори. Как правило, такие компоненты выстраиваются в довольно плоскую структуру; единственными зависимостями между ними выступают навигационные переходы. Типичный граф экранов в приложении можно поделить на подграфы в 2-5 экранов каждый, которые являются “вещами в себе” и требуют минимум внешних зависимостей и внешней координации.

Изначально коэффектами я заинтересовался как возможное решение досадной проблемы - как получить случайное число для использования в своей логике. Логика должна быть чистой, поэтому написать getRandom() посреди редьюсера нельзя. В гайде по TEA предлагается выдавать некий Effect.RandomInt и ловить ответное сообщение. Но это делает обработку изначального сообщения асинхронным и сильно усложняет структуру стейта и логики. В похожей архитектуре TCA в редьюсер передаётся некоторый Environment, который моментально делает редьюсер грязным и заставляет себя мокать в автотестах. В фреймворке re-frame же все просто - ты указываешь некий Coeffect.RandomInt и получаешь случайное число сразу же в аргументы для своей функции, описывающей логику.

Если ты работаешь с SDK карт или авторизации, тебе не нужно постоянно синхронизировать состояние точки на карте со своим стейтом. Если описать Coeffect.GetPoint то я могу опрашивать карту и получать актуальное состояние в каждый обработчик сообщений, который этого потребует. Точно так же можно иметь Coeffect.UserState который достаёт текущего юзера для моего обработчика.

Если стейт карт и текущего юзера можно получать из коэффектов, то чем “наш” стейт лучше/хуже? И как вообще определить, какой стейт “наш”, а какой уже “общий”? Поэтому я предлагаю любой стейт доставать из коэффектов, а записывать его эффектами. Это позволит также хранить куски стейта по-разному - в памяти или на диске и полностью скрыть это от нашей бизнес-логики.

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

В целом архитектура будет состоять из пяти необходимых компонентов

• MessageHandler (aka reducer) с чистой бизнес-логикой
• CoeffectHandler с обработкой коэффектов
• EffectHandler с обработкой эффектов
• Selector с подпиской на стейт
• Engine который будет связывать всё выше и следить за очередью сообщений

Получается такой классический паттерн Impureim Sandwich, где у меня сначала есть получение входных данных из грязного внешнего мира, чистая обработка нашей бизнес-логикой в середине и применение изменений к грязному внешнему миру в конце.

Классическая сигнатура Msg, State -> State, Set<Effect> упрощается до Msg, Coeffects -> Set<Effect>. Теперь стейт “такой же как все” и теряется в толпе эффектов и коэффектов. Однако мне теперь нужна ещё одна функция, выполняющая “заказ” нужных коэффектов - заведём и её: Msg -> Coeffects. Таким образом, вся бизнес-логика укладывается в две функции.

class MsgHandler(
    val coeffect: (Message) -> Coeffects,
    val update: (Message, Coeffects) -> Set<Effect<Message>>
)

EffectHandler в Puerh был достаточно хорош. Я бы и не вносил в него изменения, но всё равно есть несколько идей, как его можно улучшить. Я хочу добавить в него suspend-функции, потому что мне кажется что корутины в Android разработке надолго - нам-то точно в обозримом будущем не завезут Loom. У меня существуют некоторые предубеждения насчёт использования Flow в интерфейсе хендлера, хочется использовать более низкоуровневое API. Практика показывает, что этот приём отбивает желание пихать логику в EffectHandler. Да и концептуально хендлеры нифига не холодные потоки, а ближе к акторам. Пока что кажется, что интерфейс EffectHandler может выглядеть как-то так.

abstract class EffectHandler(
    private val continuation: suspend fun (Effect) -> Unit
) {
    abstract suspend fun handleEffect(effects: Set<Effect<*>>)
}

Ещё одно отличие в данном случае - хендлер принимает все эффекты сразу вместо того чтобы обрабатывать их по отдельности. Это сделано для того чтобы удобнее было работать с эффектами изменения стейта и обрабатывать их синхронно и транзакционно.

CoeffectHandler мог бы вообще отсутствовать, если принять коэффекты подвидом эффектов и переиспользовать сущность EffectHandler для них. Но для коэффектов существует контракт что они должны быть синхронными, ведь обработка сообщений должна быть последовательной. Поэтому обрастание саспендами тут не играет на руку.

interface CoeffectHandler {
    fun handleCoeffect(coeffects: CoeffectMap<*>): CoeffectMap<*>
}

Контракт CoeffectHandler в таком случае гласит, что он пробегается по мапе коэффектов, находит среди ключей интересующие его, исполняет их и подкладывает результат в мапу.

Так как источников правды несколько, нужна будет сущность, которая будет подписываться на коэффекты, собирать из нескольких источников стейт и отдавать его в виде ViewState в Compose или другой UI. Интерфейс его должен выглядеть так:

interface Selector{
    fun subscriptions(): CoeffectMap
    fun update(coeffects: CoeffectMap)
}

Если присмотреться, то этот интерфейс чем-то дуален MessageHandler. Не знаю, есть ли выкладки теорката под этот случай.

Engine должен связывать все компоненты воедино.

interface Engine {
    fun dispatch(message: Message)

    fun /*un*/registerEffectHandler(effectHandler: EffectHandler)
    fun /*un*/registerCoeffectHandler(coeffectHandler: CoeffectHandler)
    fun /*un*/registerMessageHandler(messageHandler: MessageHandler)
    fun /*un*/registerSelector(selector: Selector)

    fun dispose()
}