Архитектурный шаблон MVI в Kotlin Multiplatform, часть 2

[agent10]

1) А почему не использовали скажем Ktor для получения данных? Зачем разнесли в expect/actual?

Почему мы избегаем библиотеки Reaktive (или корутин/Flow) в Swift?

2) Новая инфа) А разве не в этом был смысл Reaktive? Вы её используете только в рамках jvm/андроид таргетов?

[arkivanov]

Спасибо за вопросы!

1. Здесь несколько причин:
   
   • Прежде всего Ktor немного выходит за рамки статьи
   • Ktor знаком меньшему количеству разработчиков, нежели HttpUrlConnection
   • Хотелось лишний раз продемонстрировать возможности expect/actual
2. Здесь речь именно про экспорт асинхронных фреймворков как API в Swift (или в Xcode). Из-за описанных ограничений их неудобно (и местами опасно) использовать. По-этому намного удобнее закрыть удобным и простым фасадом, а всю логику сделать деталями реализации общего модуля. Но использовать Reaktive для написания общего Kotlin кода — одно удовольствие. :-)

[agent10]

2) Тут конечно философский вопрос. В моей удобной вселенной — реактивщина и должна давать возможность проброса "примитивов"(Flow, Flowable,..) куда-то ещё, где их будешь использовать. Я понимаю, что сейчас это опасно скажем из-за native. Но почему менее удобно? В jvm/android ведь никого это особо не смущает когда rx идёт от сетевого уровня к UI..

[arkivanov]

Я с Вами полностью согласен, и в переведённом примере Rx (или это могли быть корутины+Flow) — во всех слоях, кроме прямо самого UI. И так получается, что UI можно сделать практически единственным, с чем придётся взаимодейстовать пользователям модуля. Это отлично ложится на имеющиеся ограничения Kotlin/Native. Да и просто, чем меньше пользователям модуля надо делать работы, тем лучше — на много проще вызвать метод onDestroy, чем заботится об утечках и отменах самому.

[Kostya500]

Там просто со Swift не удобно все это дергать, я конечно, только игрался с ним. Но дискомфорт как-то сразу виден, если например мы из Android кода без проблем дергаем suspend функции, то через Swift приходится использовать обычные callback-и.

[agent10]

Как бы на основе текущего примера реализовали скажем: тап на котика — показ диалога и пусть с получением какого-либо результата с диалога.
?

[arkivanov]

Показ диалогов можно делать также через состояние, а можно доработать "фреймворк" и добавить туда подобие News в MVICore. Если через состояние, то порядок примерно следующий:

• По нажатию на котика производится Event.ItemClicked, который преобразуется в Intent.DoSomething
• Intent.DoSomething поступает в Store
• Store выставляет некий флаг State.isWaitingForData
• State преобразуется во ViewModel, где проставляется флаг ViewModel.isRequestDataDialogVisible
• При успешном закрытии диалога выдаётся Event.RequestDataDialogConfirmed(data)
• При отмене диалога выдаётся Event.RequestDataDialogCancelled
• Store получается соответствующие намерения, убирает флаг State.isWaitingForData и выполняет нужное действие

Если делать через News, то вместо фалага в состоянии Store будет выдавать одноразовый News.WaitingForData. Получив этот News представление показывает диалог.

[agent10]

Ага, спасибо. А Store был бы один на сам экран и диалог?
Что если диалог сложный и интерактивный? Тогда для него следовало бы сделать отдельный Store? Т.е. вопрос больше о том где граница когда фичу/компонент пора выделять?

[arkivanov]

Мы стараемся следовать SRP. По-этому да, если диалог сложный или может быть переиспользован, то его можно вынести в отдельную сущность (в статье это Component, или DialogFragment, или в нашем случае это был бы отдельный RIB). Там был бы свой Store. Тогда показ и скрытие лучше делать через News.