SwiftUI: Реализация разделенного координатора совместно с DeepLink (Universal link)

[Bardakan]

дайте пожалуйста пример для случая, когда у экрана есть "входные" параметры

[Demtriy]

Вся же статья посвящена именно этому вопросу.

[Bardakan]

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

Возвращаемся к вопросу, на который вы в прошлый раз не ответили - зачем использовать вложенные enum, если вы их все равно потом преобразуете во "flat" тип (tuple в вашем случае)

[Demtriy]

Я не вижу никакой ценности в том, чтоб ограничивать View входящим типом модели. Тем более, что вью не использует модель напрямую, а передает ее во вью-модель. Так пусть вью-модель несет ответственность за тип обрабатываемых данных - в строго типизированной среде обобщенные данные будут всегда иметь нужный тип.

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

[Bardakan]

На проектах с таким подходом я периодически вижу например следующее - сначала переходим на экран, потом начинаем запрашивать данные, и тут выясняется, что данных-то нет по каким-то причинам, и приходится возвращаться куда-то на предыдущий экран. Хотя правильным решением было бы показать loading на предыдущем экране (в вашем случае это какой-то рутовый экран), потом показать alert с ошибкой - без переходов.
И как тогда быть со Storage? Сохранять последнюю ошибку и экран, куда нужно вернуться?

P.S. рассматриваю не только deep links, а более общую ситуацию - в том числе, когда нужно просто от одного экрана перейти к другому.

[Demtriy]

На проектах с таким подходом я периодически вижу например следующее - сначала переходим на экран, потом начинаем запрашивать данные, и тут выясняется, что данных-то нет по каким-то причинам, и приходится возвращаться куда-то на предыдущий экран.

Я тоже сталкивался с такой реализацией. Но такой подход хоть и допустимый, но строго не рекомендуемый со стороны Apple. Я тщательно его избегаю, если это вообще возможно.

Хотя правильным решением было бы показать loading на предыдущем экране (в вашем случае это какой-то рутовый экран), потом показать alert с ошибкой - без переходов.

Совершенно верно. Если использовать команды DeepLink Service без получения входящего URL, то внутри самой команды, осуществляется загрузка данных из персистивного хранилища (CD/SD) или из сети, а потом происходит активация координатора. В случае необходимости - UI перенаправляется на координатор, который содержит Alert.

И как тогда быть со Storage? Сохранять последнюю ошибку и экран, куда нужно вернуться?

P.S. рассматриваю не только deep links, а более общую ситуацию - в том числе, когда нужно просто от одного экрана перейти к другому.

Как видите из предыдущих комментариев задача легко решается без дерганий экранов туда-сюда.

Заметьте, я статьях я не рассматриваю отображение модальных окон, которые, по сути, и являются алертами. Прежде всего потому, что они не входят в StackNavigation иерархию. У меня они отображаются в отдельном ZStack слое от имени той сущности, которая инициирует ошибку (Команда DeepLink или ViewModel).

[Demtriy]

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

[Bardakan]

но вы же потом сами ломаете эту вложенность:

var screen: (String, String) {
            switch self {
                case .auth(let screen): return (Segment.auth.rawValue, screen.rawValue)
                case .profile(let screen): return (Segment.profile.rawValue, screen.rawValue)
                case .products(let screen): return (Segment.products.rawValue, screen.rawValue) // +
            }
        }

var view: some View {
            Group {
                switch self {
                    case .auth(let value): value.view
                    case .profile(let value): value.view
                    case .products(let value): value.view // +
                }
            }
        }

и это у вас только 3 "маршрута"/экрана, а вы говорите, что в проекте экранов несколько сотен

[Demtriy]

Вы, видимо, недостаточно вникли в код. Здесь не три маршрута, а три разделенных координатора. Если каждый координатор содержит 18 экранов, то Вы получаете 54! (факториал) уникальных роута. Можете играть в блек-джек.

[Bardakan]

хорошо, строк преобразования в switch case будет меньше, но вопрос остается все тот же - зачем использовать enum, если есть другие типы, которые можно использовать без лишней конвертации

[Demtriy]

Потому что enum дает однозначный маппинг строки, который опирается на название константы.