Кстати, по производительности тогда будет плюсом то, что мы не будем на каждое изменение стейта одного итема гонять diffutil, чтобы отобразить измененное состояние списка. Ведь тогда у нас будет возможность точечно менять стейты внутри списка.

если 10-20 айтемов, то может быть и ок, если это сотни то будут фризы при биндинге экрана

Хм, ну ладно. Я наивно надеялся, что пара disposable, реле для управления лайфсайклом + rx-стримы, которые мы понаделаем для реализации ui-логики итема, в нашей пм будут стоит очень дешево. Но да, при скролле может биндиться сразу несколько  итемов, срабатывать сразу много rx-стримов, и это наверное и правда будет заметно :| Но все же сама идея кажется вполне естественной и справедливой.

И у меня есть ещё один небольшой вопрос. Почему, например, InputControl не реализован в виде child pm?

Когда я только познакомился с либой, мне так понравилась эта идея с контролом, что я начал пытаться писать свои, чтобы инкапсулировать в них переиспользуемую ui-логику для отдельных ui-элементов. Получалось не очень красиво и странно, но я был уверен, что контролы это вот как раз то, что нужно в таких случаях, а потом я узнал про child pm, и осознал свою ошибку.

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

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

Хотя изначально контролы решали только одну задачу - это двусторонний датабиндинг.

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

Доступ к стейтам нужно открыть в котролах, у нас еже заведена исшу по этому поводу. Наверное на выходных сделаю фикс и обновлю библиотеку

Если абстракция виджета, то лучше контрол, если связь с моделью (интеракторами и т д), то это пм-ка

Здорово, буду ждать :) И спасибо за либу, она очень классная!

До того, как познакомился с ней, экспериментировал с MVI-подходами. Пробовал писать аналогично тому, как это делают в этом блюпринте:
https://github.com/oldergod/android-architecture/tree/todo-mvi-rxjava

О, и как? Мы вот сейчас в команде думаем стоит ли пробовать в проектах

Спасибо, нам приятно что либа приносит кому-то пользу. Жаль что она не так популярна в сообществе

Помимо закрытого доступа к стейтам меня еще немного смущает реализация bindTo для контролов внутри базовой вьюшки

Концептуально очень классно все получается, весь экран как на ладони. Но конкретно в такой реализации ооочень много кода получатеся :| Плюс все отталкивается от такой экстремальной идеи, что весь экран должен быть сшит в один композитный стейт. Но иногда это больше мешает, чем помогает. Особенно когда экран состоит из несвязанных ui-стейтов.

И в итоге для несложных экранов порой было очень больно городить всю эту mvi-инфраструктуру

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

Есть идеи где это может быть?