Comments 11
дайте пожалуйста пример для случая, когда у экрана есть "входные" параметры
Вся же статья посвящена именно этому вопросу.
нет. Вы берете url, вырезаете из него параметры, сохраняете параметры в синглтон, переходите на нужный экран и забираете параметры из синглтона обратно. Почему не передать данные в нужный экран сразу, и пусть он уже решает, нужно ли кешировать где-то эти данные?
Возвращаемся к вопросу, на который вы в прошлый раз не ответили - зачем использовать вложенные enum, если вы их все равно потом преобразуете во "flat" тип (tuple в вашем случае)
Я не вижу никакой ценности в том, чтоб ограничивать View входящим типом модели. Тем более, что вью не использует модель напрямую, а передает ее во вью-модель. Так пусть вью-модель несет ответственность за тип обрабатываемых данных - в строго типизированной среде обобщенные данные будут всегда иметь нужный тип.
А вот в том, чтоб исключить ошибку при парсинге строкового пути я вижу очень высокую ценность, в особенности, если этот путь формируется строкой на стороне сервера. Если пренебрегать этим, то возможен диапазон негативных сценариев от провала навигации до креша приложения в продакшине по вине банальной опечатки бэкенд разработчика.
На проектах с таким подходом я периодически вижу например следующее - сначала переходим на экран, потом начинаем запрашивать данные, и тут выясняется, что данных-то нет по каким-то причинам, и приходится возвращаться куда-то на предыдущий экран. Хотя правильным решением было бы показать loading на предыдущем экране (в вашем случае это какой-то рутовый экран), потом показать alert с ошибкой - без переходов.
И как тогда быть со Storage? Сохранять последнюю ошибку и экран, куда нужно вернуться?
P.S. рассматриваю не только deep links, а более общую ситуацию - в том числе, когда нужно просто от одного экрана перейти к другому.
На проектах с таким подходом я периодически вижу например следующее - сначала переходим на экран, потом начинаем запрашивать данные, и тут выясняется, что данных-то нет по каким-то причинам, и приходится возвращаться куда-то на предыдущий экран.
Я тоже сталкивался с такой реализацией. Но такой подход хоть и допустимый, но строго не рекомендуемый со стороны Apple. Я тщательно его избегаю, если это вообще возможно.
Хотя правильным решением было бы показать loading на предыдущем экране (в вашем случае это какой-то рутовый экран), потом показать alert с ошибкой - без переходов.
Совершенно верно. Если использовать команды DeepLink Service без получения входящего URL, то внутри самой команды, осуществляется загрузка данных из персистивного хранилища (CD/SD) или из сети, а потом происходит активация координатора. В случае необходимости - UI перенаправляется на координатор, который содержит Alert.
И как тогда быть со Storage? Сохранять последнюю ошибку и экран, куда нужно вернуться?
P.S. рассматриваю не только deep links, а более общую ситуацию - в том числе, когда нужно просто от одного экрана перейти к другому.
Как видите из предыдущих комментариев задача легко решается без дерганий экранов туда-сюда.
Заметьте, я статьях я не рассматриваю отображение модальных окон, которые, по сути, и являются алертами. Прежде всего потому, что они не входят в StackNavigation иерархию. У меня они отображаются в отдельном ZStack слое от имени той сущности, которая инициирует ошибку (Команда DeepLink или ViewModel).
Вложенные enum используются чтоб разбить координатор на несколько частей. В прошлых частях я писал - что когда количество экранов в приложении несколько сотен - это вызывает очень большие проблемы по сопровождению кода, особенно, когда над кодом работают несколько разработчиков.
но вы же потом сами ломаете эту вложенность:
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 "маршрута"/экрана, а вы говорите, что в проекте экранов несколько сотен
SwiftUI: Реализация разделенного координатора совместно с DeepLink (Universal link)