А в MVI события не дискретные?

MVI не только про объект, но и про подписку.
Теоретически, в MVP можно один объект скинуть на VIew. Получается, View будет иметь один метод (помимо attach/detach) - что-то типа renderState(state: State). Я не пробовал так. Не могу сказать насколько это плохо или хорошо.
Выглядит так, что View станет сильно умной, т.к. ей придётся разбираться как отрендерить state. К тому же будет не просто менять части state в презентере. Для чего в MVI есть специальная сущность - редьюсер.

а как же этот пример от сюда? https://hannesdorfmann.com/android/mosby3-mvi-2/

Как мне показалось - MVI это не альтернатива MVP/MVVM, а особенность их реализации / параллельный подход.

Точно так же можно с MVP/MVVM использовать clean или не использовать

не дискретные в том смысле что они отправляются по единому потоку, внутри потока конечно и события и стейты дискретные

я бы вообще выделил такую цепочку эволюции архитектур:
MVC + ViewInterface = MVP
MVP + Bindings = MVVM
MVVM + UDF = MVI

@ArkaNN1985 Аркадий, можете пояснить по этому вопросу? hannesdorfmann действительно из "презентера" дёргает View.
В MVIKotlin, я вижу, что IntenExecutor (типа "презентер") не знает про View, а View привязывается к Store через специальную сущность - Controller, который, по сути, является частью View.
Как в итоге правильно с точки зрения концепции MVI? Должна ли сущность, аналогичная презентеру знать про View? И почему в итоге в MVIKotlin пришли к тому, что эта сущность про View не знает?

У хенеса свое видение mvi через призму mvp. Подход с того времени эволюционировал.

Я бы не брал сейчас его статьи за основу

Потому что в mvvm - View может выдернуть состояние из VM, а в MVI нет

можно и одно и второе реализовать так, что сможет и что не сможет

но это же будет нарушением

почему?

потому что udf это return и throw
а как без return выдернуть состояние?

MVVM это “вью обзервит состояние M и передаёт M сообщения”. Ограничений на то, как сделано состояние, как сделан observe и как передаются сообщения и как состояние модифицируется - нет.
MVI это тоже “вью обзервит состояние M и передаёт M сообщения”, но с дополнительными ограничениями. Состояние - единое и иммутабельное, обновляется атомарно. Сообщения - обычно отдельные объекты. Для обновления состояния используется какой-нибудь редюсер.
Мне кажется не особо важно здесь давать точные определения и ограничивать, сколько должно быть составных частей у вашего MVI и как они будут называться. Главное - сообщения на вход и состояние на выход.

я тоже так думал. Но нарисовав uml я понял, чем они отличаются

Там приведённый фрагмент когда взят из "промежуточного" места, где Hannes Dorfmann показывает отличие отрисовки в MVP (по полям) от отрисовки в MVI (единым консистентным состоянием). Это не пример MVI. Сам пример ниже. Там фрагмент - это View, interactor - это типа Store, а presenter - это контроллер (binder).

пожалуй это самое понятное объяснение, что встречал. Спасибо =)

Надо добавить:
MVI + FP = MVU ))

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

Текстовые поля - это поля события