Как стать автором
Обновить

Комментарии 8

Я веб-разработчик.
С ELM не знаком, но по описанию он похож на другую популярную архитектуру в вебе, которая появилась позже.
Я написал статью из двух частей, в которой указываю ее проблемные моменты (это редьюсеры и использование событий там, где нет необходимости):
habr.com/ru/post/546606
habr.com/ru/post/546628

Основное отличие стора/сторов у меня в том, что там нет редьюсеров и событий.
Нет необходимости создавать функцию-редьюсер, в которой реализуется функционал нескольких функций. Вместо одной большой функции с 3-мя Event, лучше сделать 3 отдельных функции. Имя события тогда не понадобится.
У функции уже есть имя, зачем ей передавать лишнюю информацию (имя события) о том, что именно эту функцию нужно вызвать? Это конечно в некоторых ситуациях может быть полезно (чтобы уменьшить зависимость; для тестов), но пригодится далеко не во всех проектах. Да и вызвать функцию и передать ей параметры можно по имени, указав его как строку (но это в JavaScript. Как в других языках – не знаю), не заводя событий.

То есть чистые функции – это хорошо. А вот объединение функционала нескольких функций в одну (редьюсер) – это уже архитектурная ошибка, если этого можно избежать. Подробнее про редьюсеры написано в первой части моей статьи.

Но, это применимо к вебу. Не знаю, насколько это применимо к мобильной разработке.
Если вы говорите о Redux, то он был вдохновлен как раз ELM архитектурой и поэтому во многом похож.

Спасибо за статьи. Возможно эти идеи можно переложить на android, сложно сказать сразу. В андроид мире по-другому устроена работа с View, но возможно это изменится с приходом jetpack compose. Так же есть разница в языках. Например, проблема нарушения принципа Liskov решается в kotlin с помощью sealed classes, которые позволяют проверять добавление новых типов на этапе компиляции. Вызывать функцию по имени тоже проблематично — kotlin статически типизированный язык.

Так же есть некоторые различия в архитектуре, одним разбением редюсера на функии не получится ограничиться. В вашем примере событие saveTodo не является чистой фукнцией. У нее есть явная зависимость на todoController и получается, что ее запуск имеет побочные эффекты. Например это усложнит ее тестирование, поскольку придется работать с зависимостями. У нас Reducer — полностью чистая функция и не имеет такой проблемы.
Я правильно понимаю, что это по сути те же самые идеи, что redux + side-effect manager (saga, например). Или в чём-то всё таки есть отличия?
В целом Redux вдохновлен ELM архитектурой и получается, что есть много общего. Отличия незначитильные и больше относятся к тому как именно структурирован код. Например, у нас нет выделенных middleware и actions, а весь код для упрощения вынесен в Reducer и Actor.

А почему вы используете RxЖабу, а не корутины?(

Мы думали о том, чтобы использовать корутины, когда начинали проект. Но на тот момент они не были готовы для production, flow был еще в альфе. Кроме этого пришлось бы бороться с порогом входа. Большинству наших разработчков пришлось бы переучиваться и на тот момент сложнее было нанимать разработчков, уже долго работавших с корутинами.
Класс! Жаль, что вы используете RxJava, а не корутины(((
Спасибо! Возможно добавим поддержку корутин в будущем, пока мы выложили то чем пользуемся сами, а у нас в стеке именно Rx
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.