Ну я у себя вынес это внутрь контролов, а сами контролы теперь в отдельном модуле лежат и шарятся между проектами

Но лаконичность пострадала чутка(

Приходится писать что-то типа

bindWidgetControl(
            vm.textInput1 to edit_text1,
            vm.textInput2 to edit_text2
)

Ещё очень интересно выглядит MVICore от Badoo. Там как раз весь бойлерплейт убран в библиотеку. Но там решили пойти дальше и вынести MVI за пределы архитектуры presentation слоя. Кажется, получилось здорово, и вот я бы хотел познакомиться с этим делом поближе.

Смотрел их реализацию, очень странные навзания они подобрали для сущностей. На первый взягляд показалось очень много кода и большой свитч на редьюсеры

bindWidgetControl(
            vm.textInput1 to edit_text1,
            vm.textInput2 to edit_text2
)

Это метод в PmView ?

Да, bindWidgetControl в PmView, а to реализуют уже контролы

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

Если сравнивать с RxPM какие плюсы и минусы у того и другого подхода?

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

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

bindWidgetControl(
            vm.textInput1 to edit_text1,
            vm.textInput2 to edit_text2
)

А вынести в отдельный интерфейс виндеры и применять его к базовому фрагменту не вариант? В либе так и сделано, все биндеры в интерфейсе AndroidPmView

у меня есть мысли на базе RxPM попробовать MVI, сделать один типизированный экшен и стейт

А как с формами ввода в MVI, как они циклы с текствотчером рвут?

Структурирует код mvi очень здорово. В принципе, я даже с RxPM применял такой подход. Заводил внутри пм рх-поток с ивентами и редюсил их в один монолитный стейт экрана через оператор scan. Очень даже гуд, удобно, чисто и легко модифицируется, когда на ui что-то меняется/добавляется.

было бы интересно сравнить по кол-ву кода с каноничным RxPM

В проекте, где я пробовал применять mvi, я всячески избегал использования обработки ввода на лету и хранения вводимого текста в стейте. С этим действительно возникли проблемы, но, возможно, я просто тогда зря испугался и не до конца разобрался как избежать зацикливания. Вообще, просто в методе для рендеринга стейта у вьюшки нужно мьютить потоки, которые шлют интенты о введении текста в поля.

Надо, кстати, глянуть, есть ли в том блюпринте кейс с двусторонним биндингом текста (если я правильно понял, о чем речь). Я уже не помню на этот счёт.

Ещё есть реализация MVI в библиотеке Mosby от Дорфмана, но я в нее особо не заглядывал. Зато статьи про MVI у него заразительные. Собственно, с них я и начал копать такой подход.

Да, по сути именно так и реализуется основная идея MVI. В идеале ещё нужно иметь тип для внутренних ивентов, которые непосредственно меняют стейт в редюсере. А ещё, когда я пробовал такой подход с RxPM, я оставлял несколько экшенов для разных интентов, просто от каждого экшена была своя цепочка превращений во внутренние ивенты, на которые подписывался один и тот же реле, который потом scan-ом меняет стейт через редюсер.