А как именно ты видишь лаг? В смысле он прям пипец как виден или у тебя спецвзгляд? ;)

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

Или если просто играться с видимостью объектов, становится заметно

есть такое

Можешь ссылочку скинуть?

Как дома окажусь - обязательно)

Ребята, а может ли появится архитектура библиотеки в виде какой-нибудь условной диаграммы?

Вот пара ссылочек

ребят, привет! такой наброс.
правильно ли я понимаю, что в rxpm не решается проблема неконсистентного состояния view? (классический пример - список данных загрузился, а индикатор загрузки все еще крутится на переднем плане). Всякие там mvi предлагают для решения этой проблемы хранить всё состояние нашего экрана/презентера/през.-модели в ОДНОМ объекте data класса State. Он конечно же реактивный, на него подписывается view и рендерится.
В rxpm же по классике каждое маленькое свойство экрана - это отдельный observable, и на все эти observable вью подписывается независимо.
Подскажите, если где то ошибаюсь?

Никто не мешает использовать один State, если важна такого рода консистентность.

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

Пример:
две одновременные загрузки, каждая по завершении выставляет в state свойство isLoading=false
в итоге та, которая завершается раньше - выставляет false
а та что продолжается, грузится уже без индикатора

Та проблема что ты описал и в юнидирекшнал будет. Где-то это надо будет мерджить. То же самое ты руками в пм сделать должен будешь. Менять лодинг когда обе закончили для примера.

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

думаю согласен)
но тогда такой вопрос - в чем тогда плюсы юнидирекшнал, если он эту проблему не решает в итоге?

Если честно, я пока тем же вопросом задаюсь ) Кроме некоторых моментов когда чуть понятнее один Стейт чем множество, не ясно в чем супер-плюсы.

В основном наверное в том, что ты решаешь в выделенном месте как смерджить Стейт в то что надо. Видишь это явно. Когда стейтов много чуть менее явно это.

понял тебя, спасибо!

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

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

да, согласен.
возможно в стейте будет 2 флага isLoadingA, isLoadgingB
и третий флаг, который вычисляется из первых двух
и который как раз и будет отображаться на вью