Dismissing NavigationLinks and fullScreenCovers with IfLetStore programmatically

[thebarndog]

@stephencelis I found an interesting issue, one I'd like to get your thoughts on. I posted about a related issue here #996 and I figured I would create another discussion to expand on this issue.

My application does not use the standard viewStore.binding mechanism when dealing with NavigationLinks or .fullScreenCover. That is to say, my navigation links are entirely programmatic and are hidden from the user (because they're not a tappable link) so I'm faced with a situation where a true value is never sent to the binding because it's not tappable. To get around that, I use a .constant binding in the form .constant(viewStore.presentPurchasePage). Then, when the optional sub-state changes in my reducer i.e. state.purchase = .init(), the binding evaluates to true and the navigation link is presented. An example of what that might look like is:

NavigationLink("", isActive: .constant(viewStore.presentPurchasePage)) {
    IfLetStore(store.scope(\.purchase, action: AppAction.Home.purchase)) { store in 
        PurchaseView(store: store)
    }
}

The problem comes in on dismissal. I have a custom dismiss button that fires off an action that essentially amounts to setting that substate to nil, i.e. state.purchase = nil. When that happens however, the IfLetStore immediately evaluates to nil and the entire destination view disappears from the view hierarchy before the navigation link animation occurs, leaving an incredibly jarring user experience. This is also true when using fullScreenCover.

I actually did find a workaround to this issue but I don't love it. In the presented view, when the dismiss button is pressed, I dispatch viewStore.send(.dismiss, animation: .easeIn). Adding an animation causes the view dismissal transition to happen correctly and the navigation link dismisses correctly without the destination view disappearing prematurely. The reason I don't like it is because now I have to add animations to every single dispatch that causes dismissal animations to happen and the chance for user error is high. Also, the animation I pass is completely irrelevant as navigation links and full screen covers already have their own dismissal.

Have you ever seen anything like this before? Maybe it's all just user error and I would love to know how to correctly programmatically present a navigation link or full-screen cover.

[iampatbrown]

Hey @thebarndog do you have a small reproducible example? It could be similar to #953 (reply in thread)

[thebarndog]

I don't unfortunately, the example I'm working off of is closed source but if I get a free minute I'll definitely make one!

[thebarndog]

@iampatbrown to follow up on this, I believe my issue is pretty much the issue that you describe in that thread. My IfLetStores were coincidentally in a ZStack so adding the animation to the view store send fixed my transitions.

What I thought was strange though and I'm very interested to hear your thoughts on this, is that in cases where the IfLetStore is inside a navigation, the animation is essentially ignored. If for example I do viewStore.send(.someDismissalAction, animation: .easeIn(duration: 20), the navigation dismissal animation never changes (which is probably for the best). It is weird though that I can basically specify any animation irrespective of the actual transition which will always be a pop back.

I'm not 100% sure what a good solution is for this but I was thinking a variant of viewStore.send might be warranted, something like viewStore.send(.someAction, animated: true) where the boolean flag just conditionally wraps the send in a withAnimation block. Thoughts?