Problem when using TCA combined with iOS 16 NavigationStack

[WesleyHilhorst]

Hello! I'm fairly new in the SwiftUI and TCA domain, so bear with me. I like the thoughts behind it and figured, let's test it out with an iOS 16 demo app!

As I've seen the latest video's, I wanted to split up navigation/coordination from the actual view's as as much as possible, but also as easy as possible. I couldn't really find my specific issue within the current discussions.

I'm doing this by creating a RouterView which returns the views that are requested by the navigationDestination. Whenever I do an async task (i.e. using a Clock, thanks for those video's too) within the reducer, it seems that the navigationStack is refreshed and loses state completely from both the previous View when navigating back, as the View where I try navigating towards.

It might be a very core SwiftUI thing I'm doing wrong. Although it does work without TCA it seems. Any tips on what might be wrong in my example project?

[mbrandonw]

The problem is in this line. This creates a whole new store from scratch every time the view is recreated, which causes any state changes to be lost and all effects to be cancelled.

This is why in TCA, when creating child features, one scopes an existing store to pass down to the child instead of constructing a whole new one from scratch.

However, this store-scoping style does not immediately play nicely with NavigationStack. And really this is a vanilla SwiftUI problem too. As we showed in the most recent episode, if you want be able to observe what is happening in each screen of a stack you are forced to put a full-blown observable object in each case of the destination enum, which then causes coupling all over again.

So, essentially more work needs to be done to build the tools for TCA to be able to take advantage of the new iOS 16 navigation tools. That has been our focus for many months (really over a year), and it's the topic of our next series of episodes after the one we are starting next week. We will show you can take advantage of NavigationStack in TCA, and even show how it greatly improves the problems I described above for vanilla SwiftUI.

[WesleyHilhorst]

Right, to simplify and summarise, it's not really possible to get TCA working per feature/screen within a SwiftUI only app? The only way to use it, is to apply the architecture fully throughout the whole app. Defining an application reducer with child reducers?

There is no use for me applying said scoped pattern throughout the app using the NavigationStack since I will run into issues. That knowledge will save me sometime :-). I've verified it by making a vanilla SwiftUI example. It is indeed, not workable in the pattern that I'm attempting to apply.

I'm not sure how Apple thought about how to apply the NavigationStack with path property. What's the point if already in memory state is being lost whenever navigating back. Also, not sure why it seems to initialise a View where I'm navigating towards twice which causes some weird disconnect. It feel's like there is more wrong than only the view being completely redrawn.

Looking forward to next updates regarding navigation 👍🏻

Edit:
It seems even that there is a difference between using a ViewBuilder vs defining navigation views inline. You can see the difference when running previous branches against this branch .

[mbrandonw]

Right, to simplify and summarise, it's not really possible to get TCA working per feature/screen within a SwiftUI only app? The only way to use it, is to apply the architecture fully throughout the whole app. Defining an application reducer with child reducers?

That's mostly true, but maybe not 100% true. You could (theoretically) have a screen in the nav stack be built with TCA even if the parent is not built in that way. It just requires some weird steps to accomplish.

What you'd need to do is hold onto the Store inside the view as @State in order to make sure it is only created once, and not repeatedly as is the case with your code now. Something like this:

struct ListView: View {
  @State var store: StoreOf<ListViewReducer>
  …
}

And if you need a custom initializer for this view it would have to look like this:

init(store: StoreOf<ListViewReducer>) {
  self._store = State(wrappedValue: store)
}

You should try that style and see if it gets you past some hurdles.

[WesleyHilhorst]

Wow, amazing. Thank you for that info and the support! That seems to work.