ios - SwiftUI - 如何避免导航硬编码到 View 中？

Question

我尝试为更大的、可用于生产的 SwiftUI 应用程序构建架构。我一直在遇到同样的问题，这指向 SwiftUI 中的一个主要设计缺陷。

仍然没有人能给我一个完整的工作，生产就绪的答案。

如何在 SwiftUI 中做可重用的 View 其中包含导航？

如 SwiftUI NavigationLink与 View 紧密相关，这根本不可能以这样的方式扩展到更大的应用程序中。 NavigationLink在那些小样本应用程序中，是的 - 但不是当您想在一个应用程序中重用许多 View 时。也可能在模块边界上重用。 (例如:在 iOS、WatchOS 等中重用 View...)

设计问题:导航链接被硬编码到 View 中。

NavigationLink(destination: MyCustomView(item: item))

但是如果 View 包含这个 NavigationLink应该是可重复使用的 我不能硬编码 目的地。必须有一种机制来提供目的地。我在这里问了这个问题并得到了很好的答案，但仍然不是完整的答案:

SwiftUI MVVM Coordinator/Router/NavigationLink

这个想法是将目标链接注入(inject)可重用 View 。一般来说，这个想法可行，但不幸的是，这并不能扩展到真正的生产应用程序。一旦我有多个可重用的屏幕，我就会遇到一个逻辑问题，即一个可重用的 View ( ViewA )需要一个预配置的 View 目标( ViewB )。但是如果 ViewB还需要一个预配置的 View 目标 ViewC ?我需要创建 ViewB已经以这样的方式 ViewC已注入(inject) ViewB在我注入(inject)之前 ViewB进入 ViewA .等等......但由于当时必须传递的数据不可用，整个构造失败。

我的另一个想法是使用 Environment作为为 NavigationLink 注入(inject)目的地的依赖注入(inject)机制.但我认为这或多或少应该被视为一种黑客行为，而不是大型应用程序的可扩展解决方案。我们最终会基本上将环境用于所有事情。但是因为环境也可以用 只有在 View 内部(不是在单独的协调器或 View 模型中)，在我看来，这将再次创建奇怪的构造。

就像业务逻辑(例如 View 模型代码)和 View 必须分开，导航和 View 也必须分开(例如协调器模式)在 UIKit这是可能的，因为我们可以访问 UIViewController和 UINavigationController在 View 后面。 UIKit's MVC 已经有一个问题，它混合了很多概念，以至于它变成了有趣的名字“Massive-View-Controller”而不是“Model-View-Controller”。现在类似的问题在 SwiftUI 中继续存在。但在我看来更糟。 Navigation 和 Views 是强耦合的，不能解耦。因此，如果它们包含导航，则不可能进行可重用的 View 。可以在 UIKit 中解决此问题但现在我在 SwiftUI 中看不到理智的解决方案.不幸的是，Apple 没有向我们解释如何解决这样的架构问题。我们只有一些小样本应用程序。

我很想被证明是错误的。请向我展示一个干净的应用程序设计模式，它可以为大型生产就绪应用程序解决这个问题。

提前致谢。

更新:这个赏金将在几分钟后结束，不幸的是仍然没有人能够提供一个有效的例子。但是，如果我找不到任何其他解决方案并将其链接到此处，我将开始一个新的赏金来解决这个问题。感谢所有人的伟大贡献!

2020 年 6 月 18 日更新:
我从苹果那里得到了关于这个问题的答案，提出了这样的东西来解耦 View 和模型:

enum Destination {
  case viewA
  case viewB 
  case viewC
}

struct Thing: Identifiable {
  var title: String
  var destination: Destination
  // … other stuff omitted …
}

struct ContentView {
  var things: [Thing]

  var body: some View {
    List(things) {
      NavigationLink($0.title, destination: destination(for: $0))
    }
  }

  @ViewBuilder
  func destination(for thing: Thing) -> some View {
    switch thing.destination {
      case .viewA:
        return ViewA(thing)
      case .viewB:
        return ViewB(thing)
      case .viewC:
        return ViewC(thing)
    }
  }
}

我的回答是:

Thanks for the feedback. But as you see you still have the strong coupling in the View. Now "ContentView" needs to know all the views (ViewA, ViewB, ViewC) it can navigate too. As I said, this works in small sample Apps, but it does not scale to big production ready Apps.

Imagine that I create a custom View in a Project in GitHub. And then import this view in my App. This custom View does not know anything about the other views it can navigate too, because they are specific to my App.

I hope I explained the problem better.

The only clean solution I see to this problem is to separate Navigation and Views like in UIKit. (e.g. UINavigationController)

Thanks, Darko

所以对于这个问题仍然没有干净和有效的解决方案。期待 WWDC 2020。

Answer 1

关闭就是你所需要的!

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)
                }
            }
        }
    }
}

我写了一篇关于用闭包替换 SwiftUI 中的委托(delegate)模式的文章。
https://swiftwithmajid.com/2019/11/06/the-power-of-closures-in-swiftui/