У нас разброс небольшой около 3%, если не было изменений. Это достигается за счет того, что в плагине можно настраивать количество итераций билда и прогрев сборки
Конечно прям совсем точно померять не получится, но самую главную функцию - отслеживать крупные проблемы со скоростью сборки она выполняет
Сейчас :clean опциональный, это нужно, чтобы "честно" померять время сборки. Может быть кейс отслеживание времени инкрементальной сборки, плагин это тоже поддерживает. Кеши сейчас отключены, в планах сделать это настраиваемым
Все будет практически так же, как с загрузкой данных. При обработке события Init нужно отправить команду ObserveData. Actor будет выглядеть вот так:
class Actor : Actor<Command, Event> {
override fun execute(command: Command) = when (command) {
is Command.ObserveData -> ValueRepository.observeValues()
.mapEvents(Internal::OnSuccess, Internal.OnError)
}
}
Результатом выполнения команды является Observable, поэтому можно в любой из команд подписываться на обновление данных
Если вы говорите о Redux, то он был вдохновлен как раз ELM архитектурой и поэтому во многом похож.
Спасибо за статьи. Возможно эти идеи можно переложить на android, сложно сказать сразу. В андроид мире по-другому устроена работа с View, но возможно это изменится с приходом jetpack compose. Так же есть разница в языках. Например, проблема нарушения принципа Liskov решается в kotlin с помощью sealed classes, которые позволяют проверять добавление новых типов на этапе компиляции. Вызывать функцию по имени тоже проблематично — kotlin статически типизированный язык.
Так же есть некоторые различия в архитектуре, одним разбением редюсера на функии не получится ограничиться. В вашем примере событие saveTodo не является чистой фукнцией. У нее есть явная зависимость на todoController и получается, что ее запуск имеет побочные эффекты. Например это усложнит ее тестирование, поскольку придется работать с зависимостями. У нас Reducer — полностью чистая функция и не имеет такой проблемы.
Мы думали о том, чтобы использовать корутины, когда начинали проект. Но на тот момент они не были готовы для production, flow был еще в альфе. Кроме этого пришлось бы бороться с порогом входа. Большинству наших разработчков пришлось бы переучиваться и на тот момент сложнее было нанимать разработчков, уже долго работавших с корутинами.
В целом Redux вдохновлен ELM архитектурой и получается, что есть много общего. Отличия незначитильные и больше относятся к тому как именно структурирован код. Например, у нас нет выделенных middleware и actions, а весь код для упрощения вынесен в Reducer и Actor.
В целом ситуация такая, как вы описываете. Эта библиотека помогает работать со слоем, где «в элементах интерфейса изменяются данные полученные с сервера». Очень грубое ближение — если рассматривать архитектуру MVP, то наша библиотека помогает более структурированно подойти к написанию Presentation слоя. Так приходится делать, потому что android приложения со временем становятся достаточно сложными проектами и не только отображают данные с бекенда. Со временем может появляться бд, логика кеширования и синхронизации, а некоторые приложения пишут более 100 разработчиков. По нашему проекту заметно, что часто логика экрана, на котором есть несколько запросов к бекенду, становится слишком сложной. Нужно обработать множество состояний, фиче тоглов, все это покрыть тестами и написать код так, чтобы можно было через год вернуться к нему и все понять. Это усложняет архитектуру, но позволяет писать более чистый код. В целом это частое явление для андроид приложений, есть примеры и более сложных архитектур, например MVICore или RIBS от Uber. Подробнее мы рассказывали про то как к этому пришли в первой и второй частях, возможно они помогут в этом разобраться.
Спасибо за конструктивный комментарий.
1. В MVC действительно данные передаются только в одном направлении. Однако оно не регурирует то, как будет выглядеть Controller, а в нем может быть очень запутанный поток данных. MVI и подбные архитектуры имеют более подробное описание слоя представления, которое позволяет гарантировать, что даже в рамках него однонаправленность потока данных сохранится.
2. Завязка довольно условная, мы пока пользуемся в основном для написания экранов. Но итоговая версия библиотеки не будет иметь привязку ни к Андроиду, ни к экранам. А сама реализация от этого не меняется.
3. Классов действительно очень много, и это не совсем приятно. Мы облегчили себе работу тем, что написали плагин для кодогенерации. Еще можно вспомнить, что например в MVP у Presenter может быть fun onItemClick(item: Item), а в MVI вместо этого будет data class OnItemClick(val item: Item). Получается что в целом кода не становится больше из-за увеличения количество классов.
4. Все именно так, Data Store не обязательно хранилище данных, ограничения нет и если хочется можно работать в Actor с Repository или UseCase.
Скоро будет вторая часть, расскажем подробнее про то как у нас все устроено. Возможно в ближайшее время получится заопенсорсить нашу реализацию.
Если интересно что-то еще почитать про Elm, могу порекомендовать очень хорошую серию статей, правда на англоязычном Medium.
Больше людей просило версию на Flutter, на react-native пока что нет ресурсов.
Благодарю, инструмент пригодится. Вы о https://dart.dev/tools/dart-analyze?
Спасибо за комментарий! Отвечу на все по порядку:
У нас разброс небольшой около 3%, если не было изменений. Это достигается за счет того, что в плагине можно настраивать количество итераций билда и прогрев сборки
Конечно прям совсем точно померять не получится, но самую главную функцию - отслеживать крупные проблемы со скоростью сборки она выполняет
Сейчас :clean опциональный, это нужно, чтобы "честно" померять время сборки. Может быть кейс отслеживание времени инкрементальной сборки, плагин это тоже поддерживает. Кеши сейчас отключены, в планах сделать это настраиваемым
Результатом выполнения команды является Observable, поэтому можно в любой из команд подписываться на обновление данных
Спасибо за статьи. Возможно эти идеи можно переложить на android, сложно сказать сразу. В андроид мире по-другому устроена работа с View, но возможно это изменится с приходом jetpack compose. Так же есть разница в языках. Например, проблема нарушения принципа Liskov решается в kotlin с помощью sealed classes, которые позволяют проверять добавление новых типов на этапе компиляции. Вызывать функцию по имени тоже проблематично — kotlin статически типизированный язык.
Так же есть некоторые различия в архитектуре, одним разбением редюсера на функии не получится ограничиться. В вашем примере событие saveTodo не является чистой фукнцией. У нее есть явная зависимость на todoController и получается, что ее запуск имеет побочные эффекты. Например это усложнит ее тестирование, поскольку придется работать с зависимостями. У нас Reducer — полностью чистая функция и не имеет такой проблемы.
1. В MVC действительно данные передаются только в одном направлении. Однако оно не регурирует то, как будет выглядеть Controller, а в нем может быть очень запутанный поток данных. MVI и подбные архитектуры имеют более подробное описание слоя представления, которое позволяет гарантировать, что даже в рамках него однонаправленность потока данных сохранится.
2. Завязка довольно условная, мы пока пользуемся в основном для написания экранов. Но итоговая версия библиотеки не будет иметь привязку ни к Андроиду, ни к экранам. А сама реализация от этого не меняется.
3. Классов действительно очень много, и это не совсем приятно. Мы облегчили себе работу тем, что написали плагин для кодогенерации. Еще можно вспомнить, что например в MVP у Presenter может быть fun onItemClick(item: Item), а в MVI вместо этого будет data class OnItemClick(val item: Item). Получается что в целом кода не становится больше из-за увеличения количество классов.
4. Все именно так, Data Store не обязательно хранилище данных, ограничения нет и если хочется можно работать в Actor с Repository или UseCase.
Если интересно что-то еще почитать про Elm, могу порекомендовать очень хорошую серию статей, правда на англоязычном Medium.