Swiftui push pop navigation example

[Reedyuk]

The decompose examples are great but they don't demonstrate a typical navigation stack of pushing and popping.

The counter and master detail examples show a 'replace' navigation but doesn't show a push transition - this is probably the most common navigation pattern used within ios/swiftui

Maybe you could take inspiration of this:
https://quickbirdstudios.com/blog/coordinator-pattern-in-swiftui/

Also would be cool to see an example using deeplink navigation, where a user can click an item in the list and this fires off a deeplink to push a view in the navigation.

[arkivanov]

Hello. The Counter sample does demonstrate push/pop, including nested back stack.

There is also the TodoApp example, which also demonstrates push/pop.

Both examples have iOS SwiftUI attached.

[Reedyuk]

Here is a code snippet from the counter sample:

var body: some View {
        let activeChild = self.routerState.value.activeChild.instance
        
        return VStack(spacing: 8) {
            CounterView(self.counterRoot.counter)
            
            Button(action: self.counterRoot.onNextChild, label: { Text("Next Child") })
            
            Button(action: self.counterRoot.onPrevChild, label: { Text("Prev Child") })
                .disabled(!activeChild.isBackEnabled)
            
            CounterInnerView(activeChild.inner)
        }
    }

From what i can see, it's a straight replace, nothing to do with pushing and popping transition.

I was half expecting to see a NavigationView being used in swiftui

[arkivanov]

@Reedyuk Exactly, the same applicable for any other UI - Jetpack Compose, React, etc. The source of truth for the navigation is Decompose's Router. The Router exposes the navigation state, where there is an active child and a back stack (inactive children). The UI is only concerned about rendering whatever is currently active. So no need to use the NavigationView, etc. The UI subscribes to the Router state changes using the Router.state: Value<RouterState> property -> the Router pushes a new child into the stack -> the Router state is updated -> the UI receives the updated state and re-renders.

The tricky part here is animating transitions between screens. Decompose provides APIs for Jetpack Navigation. But there is nothing out-of-the-box for SwiftUI. This was discussed in #21. The explanation of why it's not possible to include animation APIs for SwiftUI into Decompose can be found in the "old" repo - badoo/Decompose/issues/228. So currently, devs have to do something on their own for animations, something similar to what we have for Jetpack Compose.

[antoniusnaumann]

Using a NavigationView can be desirable, especially when working on a SwiftUI project which targets i.e. both iOS, iPadOS and macOS to achieve visual consistency for each platform. And as far as I know, this is possible while using Decompose for Routing.

@Reedyuk From my understanding, using a NavigationView just for presentation together with a Decompose router as single source of truth should be possible by implementing a custom binding and passing it as the selection parameter in this NavigationLink constructor. Only necessary addition compared to this navigation example needed that I can see so far would be adding a tag-Property to Root.Child since NavigationLink uses tags to identify the currently selected element.

I am currently playing around with Decompose in a personal project and can add a code example if needed once I tested this approach.

[arkivanov]

@antoniusnaumann Thanks for the useful information. Please don't hesitate do add any code examples, as it may help other devs.

PS: converted this issue to a discussion.

[dkulundzic]

@antoniusnaumann, nice find on the NavigationLink initialiser. Did you perhaps progress on this one? We ran into the same problem as you did 🙂

[antoniusnaumann]

@dkulundzic Yeah, I have found a solution which works for my use case but with a few draw backs and things to be aware of. Currently I don't have much time to upload proper sample code. Here is a snippet similar to how I used it:

NavigationLink(
    destination: DestinationView(child: router.child as? RootChild.Detail),
    isActive: Binding<Bool>(
        get: { (router.child as? RootChild.Detail) != nil },
        set: { if $0 { root.yourOnOpenDetailViewMethod() } else { root.yourOnCloseDetailViewMethod() } } )
) {  /* YOUR LINK LABEL GOES HERE */  } 

(You can use EmptyView() and trigger root.onOpenDetailView()

This snippet assumes that:

• router is an observable object which wraps your routerState and exposes it as a Published property*
• You implemented a Root component similar to the one in this router example
• root.yourOnCloseDetailViewMethod() and root.yourOnOpenDetailViewMethod() are implemented in such a way that a view is pushed/popped on your router.
• DestinationView displays an error message if the casted child is null (this should never happen if implemented correctly, since get checks for that, but the compiler does not know about this) or passes child.component to the actual view which will be displayed

*observable object implementation which wraps router state. Note that Root.Child is RootChild in Swift if Root is an interface in Kotlin and Child a nested class declared inside this interface.

class Router: ObservableObject {
    private let root: Root

    @Published
    var routing: RouterState<AnyObject, RootChild>

    init(_ root: Root) {
        self.root = root
        self.routing = root.routing.value

        self.root.routing.subscribe(observer: observeRouter(state:))
    }

    private func observeRouter(state: RouterState<AnyObject, RootChild>) {
        self.routing = state
    }

    var child: RootChild { self.routing.activeChild.instance }

    deinit {
        self.root.routing.unsubscribe(observer: observeRouter(state:))
    }
}

In this example, the Decompose router is still the only source of truth. NavigationLink handles

1. The conditional logic on when to display DestinationView
2. Providing a UI element for the link which triggers a method on root to push the detail component
3. Providing a UI element for a navigation bar with back button in DetailView which triggers a method on root to pop the detail component

If you need to provide a navigation link for each of your child views, you can change the condition in get to check if the associated value of router.child matches (like an ID, a tag or a data object).

This is currently only tested for .navigationViewStyle(.stack) (the style used on iOS by default)

Most important thing to notice is that the NavigationLink has to be declared in a place where it is visible after navigating to the pushed component, so for instance in your root view. Sorry for not being able to provide a polished example, I hope this helped anyway.

[antoniusnaumann]

If you encounter any bugs or problems with this approach please let me know

[dkulundzic]

Really appreciate the time you took to write this up! I'll take a good look today 🙂

[thipokch]

I couldn't get it to work, but I'm trying to figure out what's going on here. I'm also planning to try implementing it with https://github.com/frzi/SwiftUIRouter .

[arkivanov]

I will repeat myself here again - Decompose is already a router, it holds, manages and exposes the navigation state. In the UI part (Jetpack Compose, SwiftUI, etc) you only need to subscribe to the navigation state and just switch/replace views.

Why use additional routers?

[thipokch]

@arkivanov I was just fiddling around trying to get the native animation from SwiftUI to work. Anyway the SwiftUIrouter seems to be implementing their own animation rather than the one offered by SwiftUI.

[antoniusnaumann]

For anybody still interested in this question, you should check out SwiftUIs new NavigationStack and NavigationSplitView. In short, they seem to be more flexible, especially in regard to external navigation state management and when it comes to nested navigation.

Did not have the time to play with it though.

[plusmobileapps]

I have been playing with this off and on for awhile and since I am not a swift developer, I have come up with a halfway solution for my iOS app that seems to get the job done. Although it does omit using my RootBloc to lean on the routing capabilities of NavigationStack since I was wanting the native navigation features (swipe to go back, animated title bar between destinations, etc) and reuse all my blocs for each individual screen. If you want to see all the changes I made to support this, you can check it out in this PR.

rick-and-morty-navstack.mov

My android app full utilizes decompose for all routing logic, but until there is a better solution out there that can accomplish all of these things the native swift navigation has baked into it I had to pull back some of the routing logic in my ios app to be native.

[arkivanov]

Thanks for sharing! This looks pretty good. I didn't have a chance to play with the iOS navigation yet, but I'm wondering how the new NavigationStack could help here, even though it's iOS 16.0+.

[plusmobileapps]

Of course, hope this helps someone else! The NavigationStack is also definitely an improved API over NavigationView, although I have not yet figured out how to get rid of the NavigationLink since it requires the value for the route at that time. Although you can still technically observe changes in the root view and update the path, but it requires you to update the paths starting from the 2nd onward in an array and updating the current view in the NavigationStack.

Even if it's only available on iOS 16+, I personally don't think that is as big of a deal since Apple releases the os on the same day to all devices practically in the last 6 years as opposed to Android.

[azlekov]

Anyone having updates on this, maybe some more code snippets for NavigationView + NavigationLink?

[arkivanov]

I'm going to play with it in the coming weeks.

[ttypic]

Hey, check this out #268, maybe it will be useful for somebody. Trying to make native iOS navigation friendly to Decompose using UIKit interop