MVI и SwiftUI – одно состояние

[dempfi]

Вот очень не люблю когда используют слово intent для, по сути, моделирования действий для достижения этого самого замысла. Как пример, я как пользователь, открываю офисный пакет с замыслом написать новое резюме на новое место работы о чем офисный пакет и понятия не имеет — он только видит действие (запуск программы).

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

И это очень кривая дорожка, когда инженер начинает предполагать, что совершение действий и есть замысел пользователя — ну вот никогда не будет у пользователя замысла нажать кнопку «Д». Он не будет просыпаться с утра и думать «ах да, надо не забыть нажать кнопку «Д» в программе Х». Все это ведёт к появлению абсолютно бесполезных программ и неработающих концепций.

Извините что немного не по теме статьи написал, затриггерило :)

[PS_erg]

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

А разве не для этого сделали @StateObject? Создали экземпляр в родительской View, передали в дочернюю и ничего синхронизировать не надо.

[VAnsimov]

@StateObject доступен только с iOS 14. Этот значит, не все могут воспользоваться таким вариантом. В статье я писал, и еще раз озвучу, что эта реализация, не единственно верная. Я хотел бы увидеть реализацию на @StateObject.

[PS_erg]

Тапками не кидаться, я 1с-ник. github.com/SergeyParfenoff/TestStateObject

[VAnsimov]

Увидел. Когда с одного экрана можно перейти на десяток других и нужно показывать разные Alert, основная View очень сильно «загрязняется», тогда возникает потребность вынести навигацию в отдельный слой Router. Также это снимает обязанность View следить за навигацией и выносит эту обязаность в отдельную сущность, что хорошо (принцип SOLID всегда выручают). Ваш вариант хороший, вопрос «загрязненного» основного View остается.

@StateObject немного изменяет цикл жизни атрибута. Внутри Router, если это надо, использовать можно и нужно. У кого минимальная версия iOS 14, я бы рекомендовал заменить

@ObservedObject private var intent: RootIntent
на
@StateObject private var intent: RootIntent