Staram się stworzyć architekturę dla większej, gotowej do produkcji aplikacji SwiftUI. Cały czas pracuję nad tym samym problemem, który wskazuje na poważną wadę projektową w SwiftUI.
Nadal nikt nie dał mi pełnej odpowiedzi, gotowej do produkcji.
Jak zrobić widoki wielokrotnego użytku, w SwiftUI
których znajduje się nawigacja?
Ponieważ SwiftUI
NavigationLink
jest to ściśle związane z widokiem, po prostu nie jest to możliwe w taki sposób, że skaluje się również w większych aplikacjach. NavigationLink
w tych małych próbkach działają aplikacje - tak, ale nie tak szybko, jak chcesz ponownie użyć wielu widoków w jednej aplikacji. A może też ponownie wykorzystaj granice modułów. (jak: ponowne użycie Wyświetl w iOS, WatchOS itp.)
Problem projektowy: łącza NavigationLink są zakodowane na stałe w widoku.
NavigationLink(destination: MyCustomView(item: item))
Ale jeśli widok zawierający to NavigationLink
powinno być wielokrotnego użytku, nie mogę zakodować miejsca docelowego. Musi istnieć mechanizm zapewniający miejsce docelowe. Zapytałem o to tutaj i otrzymałem całkiem dobrą odpowiedź, ale wciąż nie pełną odpowiedź:
SwiftUI MVVM Koordynator / Router / NavigationLink
Pomysł polegał na wprowadzeniu linków docelowych do widoku wielokrotnego użytku. Ogólnie pomysł działa, ale niestety nie można go skalować do prawdziwych aplikacji produkcyjnych. Gdy tylko mam wiele ekranów wielokrotnego użytku, napotykam logiczny problem, że jeden widok wielokrotnego użytku ( ViewA
) potrzebuje wstępnie skonfigurowanego miejsca docelowego widoku ( ViewB
). Ale co, jeśli ViewB
potrzebuje również wstępnie skonfigurowanego miejsca docelowego widoku ViewC
? Musiałbym tworzyć ViewB
już w taki sposób, który ViewC
jest wtryskiwany już ViewB
przed I wstrzyknąć ViewB
do ViewA
. I tak dalej .... ale ponieważ dane, które w tym czasie muszą zostać przekazane, nie są dostępne, cała konstrukcja zawodzi.
Innym pomysłem było użycie Environment
mechanizmu wstrzykiwania zależności do wstrzykiwania miejsc docelowych NavigationLink
. Myślę jednak, że należy to traktować mniej więcej jako hack, a nie skalowalne rozwiązanie dla dużych aplikacji. Skończylibyśmy na użyciu środowiska w zasadzie do wszystkiego. Ale ponieważ Środowiska można również używać tylko wewnątrz View (nie w osobnych Koordynatorach ani ViewModels), to moim zdaniem ponownie stworzy dziwne konstrukcje.
Podobnie jak logika biznesowa (np. Kod modelu widoku) i widok muszą być oddzielone, również nawigacja i widok muszą być oddzielone (np. Wzorzec koordynatora) UIKit
Jest to możliwe, ponieważ mamy dostęp do widoku UIViewController
i UINavigationController
za nim. UIKit's
MVC miał już problem, że zebrał tak wiele koncepcji, że stał się zabawną nazwą „Massive-View-Controller” zamiast „Model-View-Controller”. Teraz podobny problem utrzymuje się, SwiftUI
ale jeszcze gorzej, moim zdaniem. Nawigacja i widoki są silnie powiązane i nie można ich rozdzielić. Dlatego nie można tworzyć widoków wielokrotnego użytku, jeśli zawierają nawigację. Możliwe było rozwiązanie tego problemu, UIKit
ale teraz nie widzę rozsądnego rozwiązaniaSwiftUI
. Niestety Apple nie wyjaśniło nam, jak rozwiązać takie problemy architektoniczne. Mamy tylko kilka przykładowych aplikacji.
Chciałbym, aby udowodniono, że się mylę. Pokaż mi czysty wzór projektowania aplikacji, który rozwiązuje ten problem w przypadku dużych aplikacji gotowych do produkcji.
Z góry dziękuję.
Aktualizacja: ta nagroda skończy się za kilka minut i niestety nadal nikt nie był w stanie podać działającego przykładu. Ale zacznę nową nagrodę, aby rozwiązać ten problem, jeśli nie mogę znaleźć innego rozwiązania i połączyć go tutaj. Dziękujemy wszystkim za ich wspaniały wkład!