FlowsStacks w/ iOS 16 navigationDestination

[morluna]

Hey everyone, first off thanks @johnpatrickmorgan for FlowStacks! It's such a nice pattern to work with and I use it in all my personal projects.

I'm starting to brainstorm ideas for how FlowStacks could incorporate some of the iOS 16 improvements around navigation. First off I'll do a quick example of how I use FlowStacks today and then I'll add an example of what I have in mind. Looking for some feedback or improvements :) Thanks all.

Example of how I use FlowStacks today:

Click to expand!

import SwiftUI
import FlowStacks

struct SettingsCoordinator: View {
    enum Screen {
        case settings, notifications
    }

    @State private var routes: [Route<Screen>] = [.root(.settings, embedInNavigationView: true)]

    var body: some View {
        Router($routes) { screen, _ in
            switch screen {
            case .settings:
                SettingsView(viewModel: SettingsViewModel(actionDelegate: self))
            case .notifications:
                Text("Notifications")
            }
        }
    }
}
                             
extension SettingsCoordinator: SettingsViewActionDelegate {
    func presentNotifications() {
        routes.push(.notifications)
    }
}

protocol SettingsViewActionDelegate {
    func presentNotifications()
}

final class SettingsViewModel: ObservableObject {
    var actionDelegate: SettingsViewActionDelegate?

    init(actionDelegate: SettingsViewActionDelegate? = nil) {
        self.actionDelegate = actionDelegate
    }

    func notificationsButtonTapped() {
        actionDelegate?.presentNotifications()
    }
}

struct SettingsView: View {
    @StateObject var viewModel: SettingsViewModel

    var body: some View {
        List {
            Button(
                "Notificiation Settings",
                action: viewModel.notificationsButtonTapped
            )
        }
        .navigationTitle("Settings")
    }
}

New DestinationRouter suggestion

My idea is to create a new "Router" view, which I call DestinationRouter for lack of a better name. Here is the definition:

@available(iOS 16, *)
struct DestinationRouter<Screen: Hashable, DestinationView: View, Content: View>: View {
    let embedInNavigation: Bool
    
    /// The array of routes that represents the navigation stack.
    @Binding var routes: [Screen]
    
    @ViewBuilder let root: () -> Content

    /// A closure that builds a `ScreenView` from a `Screen`and its index.
    @ViewBuilder var routing: (Screen) -> DestinationView
    
    public init(
        _ routes: Binding<[Screen]>,
        embedInNavigation: Bool = false,
        @ViewBuilder root: @escaping () -> Content,
        @ViewBuilder routing: @escaping (Screen) -> DestinationView
    ) {
        self._routes = routes
        self.embedInNavigation = embedInNavigation
        self.root = root
        self.routing = routing
    }
    
    var body: some View {
        if embedInNavigation {
            NavigationStack(path: $routes) {
                root().navigationDestination(for: Screen.self) { screen in
                    routing(screen)
                }
            }
        } else {
            root().navigationDestination(for: Screen.self) { screen in
                routing(screen)
            }
        }
    }
}

Then we could "refactor" the snippet in the previous section like this:

struct SettingsCoordinator: View {
    enum Screen {
        case notifications
    }
    
    @State var routes: [Screen] = []
    
    var body: some View {
        DestinationRouter($routes, embedInNavigation: true) {
            SettingsView(viewModel: SettingsViewModel(actionDelegate: self))
        } routing: { screen in
            switch screen {
            case .notifications:
                Text("Notifications")
            }
        }
    }
}

The biggest differences here are:

1. In the "Screen" enum, you no longer define the "root" screen since that will be in the body of the DestinationRouter.
2. The "routing" closure will be the one to define the screens that the view can route to.
3. embedInNavigation appears at the view level instead of the "Screen" level.

Conclusion

I know there may be even better improvements, but hoping this can start some sort of conversation!

[johnpatrickmorgan]

Thanks so much @morluna for kicking off this discussion. I've also given this a little thought, and have a couple of suggestions. But first, to address your main points:

1. In the "Screen" enum, you no longer define the "root" screen since that will be in the body of the DestinationRouter.

I like this change to have a single fixed root screen. It does restrict how you can use FlowStacks, but I think it's for the better. E.g. I've seen people hit issues where they try to incorporate two discrete flows within one coordinator (for example, logged out and logged in flows), rather than splitting them between two coordinators and switching between the two. I'd like to hear if anyone disagrees with this direction.

2. The "routing" closure will be the one to define the screens that the view can route to.

I think the main advantage of SwiftUI's new navigation APIs over FlowStacks is that they allow the handling of screen creation (navigationDestination) to be decoupled from the top-level router (NavigationStack). This breaks type safety (as it becomes possible to push any value onto the stack), but allows sub-flows to be more easily composed into a single stack, which has been requested in FlowStacks: see issue #23 for example.

3. embedInNavigation appears at the view level instead of the "Screen" level.

This is sadly not compatible with a stack that handles both presentation and navigation. See this discussion for more info.

Alternatives

Personally, I've considered two options for how FlowStacks might develop:

1. FlowStacks keeps the API it currently has

FlowStacks has some advantages over the new navigation APIs:

• it has more type safety in guaranteeing that there will be a view builder for any screen data you push.
• it can be used for presenting sheets and modals too.
• it works on earlier OS versions.
• it allows the root screen to be switched out.

2. FlowStacks evolves to match the new navigation APIs

It would look exactly like the navigation APIs (switching navigation to flow) but would offer the advantage of working on earlier OS versions and allowing sheets and modals to be presented too. E.g. it might look like this if you used a FlowPath (though you would be able to use a Array<Route<Screen>> too):

Click to view demo code

import FlowStacks
import SwiftUI

struct ContentView: View {
  @State var path = FlowPath()

  var body: some View {
    FlowStack(path: $path, embedRootInNavigationView: true) {
      HomeView()
        .flowDestination(for: NumberList.self, destination: { numberList in
          NumberListView(numberList: numberList)
        })
        .flowDestination(for: Int.self, destination: { number in
          NumberView(number: number, goBackToRoot: { path.goBackToRoot()) })
        })
        .flowDestination(for: EmojiVisualisation.self, destination: { visualisation in
          EmojiView(visualisation: visualisation)
        })
    }
  }
}

// Screen Views

struct HomeView: View {
  var body: some View {
    VStack(spacing: 8) {
      FlowLink(value: NumberList(range: 0 ..< 100), label: { Text("Pick a number") }, style: .presentSheet(embedInNavigationView: true))
    }.navigationTitle("Home")
  }
}

struct NumberListView: View {
  let numberList: NumberList
  var body: some View {
    List {
      ForEach(numberList.range, id: \.self) { number in
        FlowLink("\(number)", value: number, style: .push)
      }
    }.navigationTitle("List")
  }
}

struct NumberView: View {
  let number: Int
  let goBackToRoot: () -> Void

  var body: some View {
    VStack(spacing: 8) {
      Text("\(number)")
      FlowLink(
        value: number + 1,
        label: { Text("Show next number") }, 
        style: .push
      )
      FlowLink(
        value: EmojiVisualisation(emoji: "🐑", count: number),
        label: { Text("Visualise with sheep") }, 
        style: .push
      )
      Button("Go back to root", action: goBackToRoot)
    }.navigationTitle("\(number)")
  }
}

struct EmojiView: View {
  let visualisation: EmojiVisualisation

  var body: some View {
    Text(visualisation.text)
      .navigationTitle("Visualise \(visualisation.count)")
  }

// Models

struct NumberList: Hashable {
  let range: Range<Int>
}

struct EmojiVisualisation: Hashable {
  let emoji: String
  let count: Int
  
  var description: String {
    Array(repeating: emoji, count: count).joined()
  }
}
}

That would be similar to your proposal @morluna, but with the advantages of having a familiar API and allowing decoupling of screen creation.