Комментарии 3
Красиво пишите. Еще и ссылок много – видно, что стараетесь базой подтверждать каждую свою мысль. Продолжайте, таких авторов в иосе немного.
Разрешите добавлю по теме статьи.
Паттерны в SwiftUI не упоминаются, кмк, по одной простой причине – изменений нет. Это все тот же MVC. Но теперь это MVC в стандартной реализации, а не в модифицированной версии Cocoa от Apple.
Поясню.
Все знают MVC в виде с рисунка 7.2 (как раз модификация от Apple), но мало кто знает оригинальную модификацию с рисунка 7.1. Так вот, если Вы возьмете вашу картинку Архитектуру State-Model-View из статьи и дорисуете к ней сверху контроллер, как медиатор между View и Model, то Вы получите полностью канонический MVC с картинки 7.1. А в описании увидите и про биндинги, и про состояние.
"Но в SwiftUI нет контроллеров", – возразите Вы.
На что я отвечу, что они есть, просто Apple сделала их полностью абстрактными и скрытыми от программиста, переместив все, что раньше размещали в контроллере, на вью SwiftUI. Поэтому какой бы экран вы не верстали на SwiftUI, контроллер, рисующий экран, у вас все равно будет. Полностью абстрактный.
Отсюда, кстати, и очень важные следствия:
А все ли из того, что традиционно размещают в контроллере возможно перенести на вью?
Подсказка. Обратите внимание, какие взаимодействия идут напрямую от View к Model в MVC, а какие через Controller.
А если что-то переносить не стоит, то как использовать SwiftUI с кастомизированным, а не абстрактным контроллером? А это возможно.
А стоило ли Apple делать полностью абстрактный контроллер и прятать его от разработчиков? Не приведет ли это к путанице и новым связностям? – Подсказка: уже приводит.
В итоге, глубокое понимание того, что должно быть в контроллере, а что во вью, кажется, не даст испортить подход на SwiftUI и повторить уже классические ошибки с MassiveSwiftUI. Вы правильно указали, что проблема MassiveViewController легко решается. Так вот сейчас сообществу необходимо будет понять эту разницу, чтобы не испортить всю идею MassiveSwiftUI подходом. Что-то из этого Вы уже тоже предложили.
Ваше мнение?
ПС: Apple еще и Coordinating Controller описывает, который очень перекликается с комбинациями визуальных элементов ("Combine" pattern) и управлением переходами, которые вы описываете.
Спасибо за дельный комментарий!
Так как SwiftUI реализует высокоуровневый слой над UIKit (мы здесь говорим про iOS), то конечно UIViewController продолжает существовать и функционировать в архитектуре. IMO прекрасно, что SwiftUI-разработчик с ним не работает и может быть знает о его существовании только по нечастым случаям следов сообщений в дебаг-логе.
Если посмотреть на исходные идеи MVC конца 1970-х, то контроллер представляет специальную сущность для пользователя управлять состоянием приложения. Это принципиальный архитектурный шаг вперед от терминальных (консольных) приложений с последовательным синхронным (то есть в данном случае вида вопрос - ответ) диалогом к многооконному асинхронному интерфейсу и архитектуре, управляемой множеством событий.
Любая асинхронная архитектура, управляемая событиями (то есть когда приложение продолжает работать без остановки для ожидания следующей порции ввода пользователя как ранее в консольных программах) так или иначе реализует идею контроллера, как бы его не называли.
Мне нравится как элегантно инженеры Apple с учетом требований совместимости решили возможно самую большую проблему для большинства начинающих программистов UIKit передавать изменения состояний из одного экрана в другие. И многие другие вещи.
В итоге, если проверенный временем UIKit традиционно ориентирует внимание разработчика на детали как управлять событиями и состояниями в приложении (отсюда и повышенное внимание разработчиков к паттернам проектирования), то SwiftUI - более высокоуровневый фреймворк это умеет сам (то есть работает контроллером, сам строит констрейнты, управляет событиями, экранными представлениями) и по сути ориентирует разработчика на то, что ему предстоит сделать. Прекрасно!
IMHO, как раз вот не все из функций контроллера SwiftUI умеет делать хорошо. Есть вещи, которые как раз существенно лучше реализуются через механизмы уже имеющиеся в контроллерах, но про которые разработчики почему-то забыли и пытаются их костылить в обертке SwiftUI. Но навязывать свое мнение не стану. В остальном согласен. Обёрточка вышла годной. Просто прошу не забывать (а если не знали, то узнать) о том, что под ней и что и так работает прекрасно.
Публикации
SwiftUI: архитектура State-Model-View