New APIs - Please feedback on rewriting FlowStacks

[johnpatrickmorgan]

I've been experimenting with new FlowStacks APIs based on the latest SwiftUI NavigationStack APIs. I've rewritten the library with essentially the same entities, but with Navigation replaced with Flow:

🔀 NavigationStack -> FlowStack

🔀 NavigationLink -> FlowLink

🔀 NavigationPath -> FlowPath

🔀 navigationDestination -> flowDestination

🔀 NavigationPath.CodableRepresentation -> FlowPath.CodableRepresentation

The FlowStacks APIs expand the NavigationStack APIs:

• As well as managing navigation, you can manage sheet and full-screen cover presentation.
• A FlowNavigator environment object allows you to easily push, pop, present etc. from deep in your view hierarchy.
• The flowDestination APIs also make the screen's data available as a Binding.
• Not limited to just the latest versions of SwiftUI.

These APIs offer advantages in decoupling the building of screens from managing flow state, so you can more easily break up navigation across different files or modules, and should feel familiar to SwiftUI users.

The main disadvantage I see is that you can no longer change the root screen via the routes array or path. However, I think that leads to better modelling of app flows.

Here's the branch if you'd like to try it out - I'd like to hear opinions on this rewrite before committing to it as it's a significant change. Thanks!

[johnpatrickmorgan]

Here's an example of rewriting code that uses the current FlowStacks APIs:

Current API

enum Screen {
  case home
  case numberList
  case numberDetail(Int)
}

struct AppCoordinator: View {
  @State var routes: Routes<Screen> = [.root(.home)]
    
  var body: some View {
    Router($routes) { screen, _ in
      switch screen {
      case .home:
        HomeView()
      case .numberList:
        NumberListView()
      case .numberDetail(let number):
        NumberDetailView(number: number)
      }
    }
  }
}

Proposed API

enum Screen {
  case numberList
  case numberDetail(Int)
}

struct AppCoordinator: View {
  @State var routes: Routes<Screen> = []
    
  var body: some View {
    FlowStack(path: $routes) { 
      HomeView()
        .flowDestination(for: Screen.self) { screen in
          switch screen {
          case .numberList:
            NumberListView()
          case .numberDetail(let number):
            NumberDetailView(number: number)
        }
    }
  }
}

There's no longer a type guarantee that the routes array's screen type matches the destination builder's screen argument, but that's what allows the destination builder to be decoupled from the state management. The root screen is no longer part of the routes array, which might be awkward if your flow required you to swap out the root screen. In those cases, I imagine you would need to either:

• Have a root screen that conditionally shows one root or the other, OR
• Split the flow into two separate flows, each with a FlowStack and a parent view that switches between them as needed.

[DavidKmn]

Great work @johnpatrickmorgan, playing around on the new branch this week. The plan is to add this new api and slowly deprecate the other api?

[DavidKmn]

Also I suspect this fixes #47 ?

[johnpatrickmorgan]

The plan is to add this new api and slowly deprecate the other api?

Yes, assuming people are happy with the new API.

Also I suspect this fixes #47 ?

Sadly, I don't believe it does, as we're still using the same NavigationView API under the hood.

[DavidKmn]

Sad, that warning is really annoying, have you found a way to maybe mute it?

[DavidKmn]

Also think an example with a View Model (ObservableObject) would be a good to have in the discussion

[johnpatrickmorgan]

Good idea, I'll try to add that.

[johnpatrickmorgan]

I've (finally!) added an example now.

[DavidKmn]

Speaking no the main disadvantage of not being able to start off with the root through the routes array, how do you propose we go about a case where the root view needs a view model to be initialised?

[johnpatrickmorgan]

I'll try and include that in the example, but I assume the root view model would be stored in the same place as the Routes array / FlowPath.

[johnpatrickmorgan]

Here's an example.

[savage7]

I like the new api 😊 @johnpatrickmorgan, great work! I don't see a major disadvantage with the missing root navigation, basically thats the same with now having a path or specific flow for tab based navigation.

How are subflows/coordinators handled with this approach? I didn't look at the code but I guess that every FlowStack has its FlowPathNavigator or are they shared when a FlowStack is used within another FlowStack?

[johnpatrickmorgan]

Thanks @savage7 - I'm currently looking into the best way to allow composition of FlowStacks, and I'm exploring the possibility that child FlowStacks might defer their state management to their parent FlowStack. This should work well if the child FlowStack wasn't created with its own state binding, but might have to be treated as an error if the child has an Array binding. And perhaps the outer and inner state could be synced if the child has its own FlowPath binding.

		Inner FlowStack Binding
		NONE	PATH	ARRAY
Outer FlowStack Binding	N	✅	Sync with outer?	🚫
	P	✅	Sync with outer?	🚫
	A	Add utilities to transform inner types?	🚫	🚫 or sync if same type?

[mbuchetics]

@johnpatrickmorgan what's the current state here? I am thinking about using FlowStacks in a new project and I am wondering whether I should use the latest released version or the new-api branch?

[johnpatrickmorgan]

Hi @mbuchetics! I expect the library to adopt the proposed API at some point, but I still have outstanding tasks (documentation, tests, work on composition of child FlowStacks discussed above). I haven't had the time to dedicate to these tasks recently so I don't expect to release the new API for a while still. I would recommend you use the current released version. It shouldn't be too painful to migrate to the new API when it's eventually ready, though I would recommend you avoid using a single Router if it means you need to swap out the root screen. In that case, I would recommend having multiple Routers, one for each root screen.

[Aduci01]

Dear @johnpatrickmorgan , thank you for the great framework. Since this rewriting experiment is over 2 years old, may I ask you if you still consider finishing it?

[johnpatrickmorgan]

Sorry for the delay - it's now released as v0.6.0.

[johnpatrickmorgan]

Thanks for your patience - this rewrite has been a long time in the works but has now been released as v0.6.0. Please try it out and let me know if you encounter any issues. If you want to migrate an existing project, please see the migration docs. Thank you!