可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):
问题:
I try to do the architecture for a bigger, production ready SwiftUI App. I am running all the time into the same problem which points to a major design flaw in SwiftUI.
Still nobody could give me a full working, production ready answer.
How to do reusable Views in SwiftUI which contain navigation?
As the SwiftUI NavigationLink is strongly bound to the view this is simply not possible in such a way that it scales also in bigger Apps. NavigationLink in those small sample Apps works, yes - but not as soon as you want to reuse many Views in one App. And maybe also reuse over module boundaries. (like: reusing View in iOS, WatchOS, etc...)
The design problem: NavigationLinks are hardcoded into the View.
NavigationLink(destination: MyCustomView(item: item))
But if the view containing this NavigationLink should be reusable I can not hardcode the destination. There has to be a mechanism which provides the destination. I asked this here and got quite a good answer, but still not the full answer:
SwiftUI MVVM Coordinator/Router/NavigationLink
The idea was to inject the Destination Links into the reusable view. Generally the idea works but unfortunately this does not scale to real Production Apps. As soon as I have multiple reusable screens I run into the logical problem that one reusable view (ViewA) needs a preconfigured view-destination (ViewB). But what if ViewB also needs a preconfigured view-destination ViewC? I would need to create ViewB already in such a way that ViewC is injected already in ViewB before I inject ViewB into ViewA. And so on.... but as the data which at that time has to be passed is not available the whole construct fails.
Another idea I had was to use the Environment as dependency injection mechanism to inject destinations for NavigationLink. But I think this should be considered more or less as a hack and not a scalable solution for large Apps. We would end up using the Environment basically for everything. But because Environment also can be used only inside View's (not in separate Coordinators or ViewModels) this would again create strange constructs in my opinion.
Like business logic (e.g. view model code) and view have to be separated also navigation and view have to be separated (e.g. the Coordinator pattern) In UIKit it's possible because we access to UIViewController and UINavigationController behind the view. UIKit's MVC already had the problem that it mashed up so many concepts that it become the fun-name "Massive-View-Controller" instead of "Model-View-Controller". Now a similar problem continues in SwiftUI but even worse in my opinion. Navigation and Views are strongly coupled and can not be decoupled. Therefore it's not possible to do reusable views if they contain navigation. It was possible to solve this in UIKit but now I can't see a sane solution in SwiftUI. Unfortunately Apple did not provide us an explanation how to solve architectural issues like that. We got just some small sample Apps.
I would love to be proven wrong. Please show me a clean App design pattern which solves this for big production ready Apps.
Thanks in advance.
Update: this bounty will end in a few minutes and unfortunately still nobody was able to provide a working example. But I will start a new bounty to solve this problem if I can't find any other solution and link it here. Thanks to all for their great Contribution!
回答1:
The closure is all you need!
struct ItemsView<Destination: View>: View {
let items: [Item]
let buildDestination: (Item) -> Destination
var body: some View {
NavigationView {
List(items) { item in
NavigationLink(destination: self.buildDestination(item)) {
Text(item.id.uuidString)
}
}
}
}
}
I wrote a post about replacing the delegate pattern in SwiftUI with closures.
https://swiftwithmajid.com/2019/11/06/the-power-of-closures-in-swiftui/
回答2:
My idea would pretty much be a combination of Coordinator and Delegate pattern. First,
create a Coordinator class:
struct Coordinator {
let window: UIWindow
func start() {
var view = ContentView()
window.rootViewController = UIHostingController(rootView: view)
window.makeKeyAndVisible()
}
}
Adapt the SceneDelegate to use the Coordinator :
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
if let windowScene = scene as? UIWindowScene {
let window = UIWindow(windowScene: windowScene)
let coordinator = Coordinator(window: window)
coordinator.start()
}
}
Inside of ContentView, we have this:
struct ContentView: View {
var delegate: ContentViewDelegate?
var body: some View {
NavigationView {
List {
NavigationLink(destination: delegate!.didSelect(Item())) {
Text("Destination1")
}
}
}
}
}
We can define the ContenViewDelegate protocol like this:
protocol ContentViewDelegate {
func didSelect(_ item: Item) -> AnyView
}
Where Item is just a struct which is identifiable, could be anything else (e.g id of some element like in a TableView in UIKit)
Next step is to adopt this protocol in Coordinator and simply pass the view you want to present:
extension Coordinator: ContentViewDelegate {
func didSelect(_ item: Item) -> AnyView {
AnyView(Text("Returned Destination1"))
}
}
This has so far worked nicely in my apps. I hope it helps.
回答3:
Something that occurs to me is that when you say:
But what if ViewB also needs a preconfigured view-destination ViewC? I would need to create ViewB already in such a way that ViewC is injected already in ViewB before I inject ViewB into ViewA. And so on.... but as the data which at that time has to be passed is not available the whole construct fails.
it's not quite true. Rather than supplying views, you can design your re-usable components so that you supply closures which supply views on demand.
That way the closure which produces ViewB on demand can supply it with a closure which produces ViewC on demand, but the actual construction of the views can happen at a time when the contextual information that you need is available.
回答4:
Here is a fun example of drilling down infinitely and changing your data for the next detail view programmatically
import SwiftUI
struct ContentView: View {
@EnvironmentObject var navigationManager: NavigationManager
var body: some View {
NavigationView {
DynamicView(viewModel: ViewModel(message: "Get Information", type: .information))
}
}
}
struct DynamicView: View {
@EnvironmentObject var navigationManager: NavigationManager
let viewModel: ViewModel
var body: some View {
VStack {
if viewModel.type == .information {
InformationView(viewModel: viewModel)
}
if viewModel.type == .person {
PersonView(viewModel: viewModel)
}
if viewModel.type == .productDisplay {
ProductView(viewModel: viewModel)
}
if viewModel.type == .chart {
ChartView(viewModel: viewModel)
}
// If you want the DynamicView to be able to be other views, add to the type enum and then add a new if statement!
// Your Dynamic view can become "any view" based on the viewModel
// If you want to be able to navigate to a new chart UI component, make the chart view
}
}
}
struct InformationView: View {
@EnvironmentObject var navigationManager: NavigationManager
let viewModel: ViewModel
// Customize your view based on more properties you add to the viewModel
var body: some View {
VStack {
VStack {
Text(viewModel.message)
.foregroundColor(.white)
}
.frame(width: 300, height: 300)
.background(Color.blue)
NavigationLink(destination: navigationManager.destination(forModel: viewModel)) {
Text("Navigate")
}
}
}
}
struct PersonView: View {
@EnvironmentObject var navigationManager: NavigationManager
let viewModel: ViewModel
// Customize your view based on more properties you add to the viewModel
var body: some View {
VStack {
VStack {
Text(viewModel.message)
.foregroundColor(.white)
}
.frame(width: 300, height: 300)
.background(Color.red)
NavigationLink(destination: navigationManager.destination(forModel: viewModel)) {
Text("Navigate")
}
}
}
}
struct ProductView: View {
@EnvironmentObject var navigationManager: NavigationManager
let viewModel: ViewModel
// Customize your view based on more properties you add to the viewModel
var body: some View {
VStack {
VStack {
Text(viewModel.message)
.foregroundColor(.white)
}
.frame(width: 300, height: 300)
.background(Color.green)
NavigationLink(destination: navigationManager.destination(forModel: viewModel)) {
Text("Navigate")
}
}
}
}
struct ChartView: View {
@EnvironmentObject var navigationManager: NavigationManager
let viewModel: ViewModel
var body: some View {
VStack {
VStack {
Text(viewModel.message)
.foregroundColor(.white)
}
.frame(width: 300, height: 300)
.background(Color.green)
NavigationLink(destination: navigationManager.destination(forModel: viewModel)) {
Text("Navigate")
}
}
}
}
struct ViewModel {
let message: String
let type: DetailScreenType
}
enum DetailScreenType: String {
case information
case productDisplay
case person
case chart
}
class NavigationManager: ObservableObject {
func destination(forModel viewModel: ViewModel) -> DynamicView {
DynamicView(viewModel: generateViewModel(context: viewModel))
}
// This is where you generate your next viewModel dynamically.
// replace the switch statement logic inside with whatever logic you need.
// DYNAMICALLY MAKE THE VIEWMODEL AND YOU DYNAMICALLY MAKE THE VIEW
// You could even lead to a view with no navigation link in it, so that would be a dead end, if you wanted it.
// In my case my "context" is the previous viewMode, by you could make it something else.
func generateViewModel(context: ViewModel) -> ViewModel {
switch context.type {
case .information:
return ViewModel(message: "Serial Number 123", type: .productDisplay)
case .productDisplay:
return ViewModel(message: "Susan", type: .person)
case .person:
return ViewModel(message: "Get Information", type: .chart)
case .chart:
return ViewModel(message: "Chart goes here. If you don't want the navigation link on this page, you can remove it! Or do whatever you want! It's all dynamic. The point is, the DynamicView can be as dynamic as your model makes it.", type: .information)
}
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
.environmentObject(NavigationManager())
}
}
回答5:
I'm writing a blog posts series on creating a MVP + Coordinators approach in SwiftUI which may be useful:
https://lascorbe.com/posts/2020-04-27-MVPCoordinators-SwiftUI-part1/
The full project is available on Github:
https://github.com/Lascorbe/SwiftUI-MVP-Coordinator
I'm trying to do it as if it'd be a big app in terms of scalability. I think I've sorted out the navigation problem, but I still have to see how to do deep linking, which is what I'm currently working on. I hope it helps.
回答6:
This is a completely off-the-top-of-my-head answer, so will probably turn out to be nonsense, but I'd be tempted to use a hybrid approach.
Use the environment to pass through a single coordinator object - lets call it NavigationCoordinator.
Give your re-usable views some sort of identifier which is set dynamically. This identifier gives semantic information corresponding to the client application's actual use case and navigation hierarchy.
Have the re-usable views query the NavigationCoordinator for the destination view, passing their identifier and the identifier of the view type they are navigating to.
This leaves the NavigationCoordinator as a single injection point, and it's a non-view object which can be accessed outside the view hierarchy.
During setup you can register the right view classes for it to return, using some sort of matching with the identifiers it's passed at runtime. Something as simple as matching with the destination identifier might work in some cases. Or matching against a pair of host and destination identifiers.
In more complex cases you can write a custom controller which takes account of other app-specific information.
Since it is injected via the environment, any view can override the default NavigationCoordinator at any point and supply a different one to its subviews.
回答7:
I will try to answer your points one by one. I will follow a little example where our View that should be reusable is a simple View that shows a Text and a NavigationLink that will go to some Destination.
I created a Gist: SwiftUI - Flexible Navigation with Coordinators
if you want to have a look at my full example.
The design problem: NavigationLinks are hardcoded into the View.
In your example it is bound to the View but as other answers have already shown, you can inject the destination to your View type struct MyView<Destination: View>: View. You can use any Type conforming to View as your destination now.
But if the view containing this NavigationLink should be reusable I can not hardcode the destination. There has to be a mechanism which provides the destination.
With the change above, there are mechanisms to provide the type. One example is:
struct BoldTextView: View {
var text: String
var body: some View {
Text(text)
.bold()
}
}
struct NotReusableTextView: View {
var text: String
var body: some View {
VStack {
Text(text)
NavigationLink("Link", destination: BoldTextView(text: text))
}
}
}
will change to
struct ReusableNavigationLinkTextView<Destination: View>: View {
var text: String
var destination: () -> Destination
var body: some View {
VStack {
Text(text)
NavigationLink("Link", destination: self.destination())
}
}
}
and you can pass in your destination like this:
struct BoldNavigationLink: View {
let text = "Text"
var body: some View {
ReusableNavigationLinkTextView(
text: self.text,
destination: { BoldTextView(text: self.text) }
)
}
}
As soon as I have multiple reusable screens I run into the logical problem that one reusable view (ViewA) needs a preconfigured view-destination (ViewB). But what if ViewB also needs a preconfigured view-destination ViewC? I would need to create ViewB already in such a way that ViewC is injected already in ViewB before I inject ViewB into ViewA. And so on....
Well, obviously you need some kind of logic that will determine your Destination. At some point you need to tell the view what view comes next. I guess what you're trying to avoid is this:
struct NestedMainView: View {
@State var text: String
var body: some View {
ReusableNavigationLinkTextView(
text: self.text,
destination: {
ReusableNavigationLinkTextView(
text: self.text,
destination: {
BoldTextView(text: self.text)
}
)
}
)
}
}
I put together a simple example that uses Coordinators to pass around dependencies and to create the views. There is a protocol for the Coordinator and you can implement specific use cases based on that.
protocol ReusableNavigationLinkTextViewCoordinator {
associatedtype Destination: View
var destination: () -> Destination { get }
func createView() -> ReusableNavigationLinkTextView<Destination>
}
Now we can create a specific Coordinator that will show the BoldTextView when clicking on the NavigationLink.
struct ReusableNavigationLinkShowBoldViewCoordinator: ReusableNavigationLinkTextViewCoordinator {
@Binding var text: String
var destination: () -> BoldTextView {
{ return BoldTextView(text: self.text) }
}
func createView() -> ReusableNavigationLinkTextView<Destination> {
return ReusableNavigationLinkTextView(text: self.text, destination: self.destination)
}
}
If you want, you can also use the Coordinator to implement custom logic that determines the destination of your view. The following Coordinator shows the ItalicTextView after four clicks on the link.
struct ItalicTextView: View {
var text: String
var body: some View {
Text(text)
.italic()
}
}
struct ShowNavigationLinkUntilNumberGreaterFourThenItalicViewCoordinator: ReusableNavigationLinkTextViewCoordinator {
@Binding var text: String
let number: Int
private var isNumberGreaterThan4: Bool {
return number > 4
}
var destination: () -> AnyView {
{
if self.isNumberGreaterThan4 {
let coordinator = ItalicTextViewCoordinator(text: self.text)
return AnyView(
coordinator.createView()
)
} else {
let coordinator = ShowNavigationLinkUntilNumberGreaterFourThenItalicViewCoordinator(
text: self.$text,
number: self.number + 1
)
return AnyView(coordinator.createView())
}
}
}
func createView() -> ReusableNavigationLinkTextView<AnyView> {
return ReusableNavigationLinkTextView(text: self.text, destination: self.destination)
}
}
If you have data that needs to be passed around, create another Coordinator around the other coordinator to hold the value. In this example I have a TextField -> EmptyView -> Text where the value from the TextField should be passed to the Text. The EmptyView must not have this information.
struct TextFieldView<Destination: View>: View {
@Binding var text: String
var destination: () -> Destination
var body: some View {
VStack {
TextField("Text", text: self.$text)
NavigationLink("Next", destination: self.destination())
}
}
}
struct EmptyNavigationLinkView<Destination: View>: View {
var destination: () -> Destination
var body: some View {
NavigationLink("Next", destination: self.destination())
}
}
This is the coordinator that creates views by calling other coordinators (or creates the views itself). It passes the value from TextField to Text and the EmptyView doesn't know about this.
struct TextFieldEmptyReusableViewCoordinator {
@Binding var text: String
func createView() -> some View {
let reusableViewBoldCoordinator = ReusableNavigationLinkShowBoldViewCoordinator(text: self.$text)
let reusableView = reusableViewBoldCoordinator.createView()
let emptyView = EmptyNavigationLinkView(destination: { reusableView })
let textField = TextFieldView(text: self.$text, destination: { emptyView })
return textField
}
}
To wrap it all up, you can also create a MainView that has some logic that decides what View / Coordinator should be used.
struct MainView: View {
@State var text = "Main"
var body: some View {
NavigationView {
VStack(spacing: 32) {
NavigationLink("Bold", destination: self.reuseThenBoldChild())
NavigationLink("Reuse then Italic", destination: self.reuseThenItalicChild())
NavigationLink("Greater Four", destination: self.numberGreaterFourChild())
NavigationLink("Text Field", destination: self.textField())
}
}
}
func reuseThenBoldChild() -> some View {
let coordinator = ReusableNavigationLinkShowBoldViewCoordinator(text: self.$text)
return coordinator.createView()
}
func reuseThenItalicChild() -> some View {
let coordinator = ReusableNavigationLinkShowItalicViewCoordinator(text: self.$text)
return coordinator.createView()
}
func numberGreaterFourChild() -> some View {
let coordinator = ShowNavigationLinkUntilNumberGreaterFourThenItalicViewCoordinator(text: self.$text, number: 1)
return coordinator.createView()
}
func textField() -> some View {
let coordinator = TextFieldEmptyReusableViewCoordinator(text: self.$text)
return coordinator.createView()
}
}
I know that I could also create a Coordinator protocol and some base methods, but I wanted to show a simple example on how to work with them.
By the way, this is very similar to the way that I used Coordinator in Swift UIKit apps.
If you have any questions, feedback or things to improve it, let me know.
