Как мы в QIWI пришли к единому стилю взаимодействия между View и ViewModel в рамках MVVM

[Zoolander]

работаю с приложениями, в которых много компонентов, использую элементы из Redux-архитектуры

store по сути можно считать ViewModel, обернутый в любой вариант Observable
компонентов может быть очень много, прямая делегация методов может быть мучительной
поэтому часто для низовых компонентов я использую просто подписку на store

и когда бы store не обновил свое состояние — нужные компоненты сразу отобразят нужное изменение

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

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

Попробуйте, возможно, что-то в этом найдете. Но не экспериментируйте на продакшене, мозги должны привыкнуть к смеси MVVM и Redux (то, что описывается под вторым словом, способно только запутать, проще смотреть на картинку)

[rooooo]

Спасибо, интересная мысль!

[mkll]

Мне очень психологически мешает, что моя архитектура не описана у дядюшки Боба, но возможно, я не все читал.

Погодите, но есть же ReSwift. Он чем-то не устроил или просто попал в категорию «не все читал»? Я как раз в последние дни пробую его на вкус и вижу, что в случае мало-мальски серьезных приложений получу в State огромный плоский список всего-всего, и это меня смущает. Хотя это, конечно, относится к Redux в целом, а не только к ReSwift-реализации.

[zaitsevyan]

Подписка на события заставляет View хранить состояние, а этого хочется избежать, так как за это отвечает ViewModel. Когда мне говорят про MVVM, я представляю что существует ViewModel которая знает все и я могу в ЛЮБОМЙ момент подписаться на нее и получить все нужные мне значения для отображения. В Вашем же варианте, если подписаться позже чем начало отображение — часть событий просто не прийдет, если я правильно понимаю.
Соглашусь с предидущим автором сообщения про Redux. — Если у вас много значений который нужно отправить во View и они происходят одновременно — можно сделать из них простую структура и посылать все сразу. Иногда уместно посылать сразу целый большие обьекты с бд/сети, а View уже разберется как использовать данные.

[rooooo]

Подписка на события заставляет View хранить состояние, а этого хочется избежать, так как за это отвечает ViewModel

В нашей схеме вьюха просто отображает данные, полученные из viewModel.

В Вашем же варианте, если подписаться позже чем начало отображение — часть событий просто не прийдет, если я правильно понимаю.

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

Иногда уместно посылать сразу целый большие обьекты с бд/сети, а View уже разберется как использовать данные.

Мы так и делаем, обычно если много значений мы объединяем их в структуру и посылаем в одним событием:

case present(let content)

[Banannzza]

А какие были причины использования RunLoop.main.perform в методе bind? Интересно узнать аргументы за так как в проектах обычно встречается только DispatchQueue.main.async

[rooooo]

По этому поводу есть доклад от Антона Сергеева из VK: vk.com/video-147415323_456239066
Если вкратце: мы не хотим тормозить UI.

[Banannzza]

Да, я в курсе. Только вот примеры когда можно заметить разницу он не привел

[mkll]

Спасибо за статью. По-моему, это самый изящный способ связать View и ViewModel, во всяком случае, из тех, что я встречал.

[necrosoft]

Очень интересная статья, но есть пара вопросов:
1 — При таком подходе количество методов от вью модели уменьшается, но появляется один огромный метод со свитч-кейсами, по мне так, чем функции компактнее и меньше тем код лучше читается. В своей работе сталкивался с проектом где был метод setCallbacks с огромным свитч-кейсом который не умещался в 2 экрана )
2 — self.handleClosure = { [weak vm] in vm?.handle(event: $0) }//vm.handle
Лично мне не нравится когда вместо отступов много кода идет в одну строку. Строчек кода меньше, но читаемость хуже
3 — Вот эта вот штука let vm: Any?
Не люблю Any, может стоило бы создать хоть и пустой но протокол, например protocol ViewModel {} и его конформить каждой новой моделью?