Need help with setting/cleaning up scenes and tearing down the navigation stack in TCA

[ghost]

Hello everyone :)

Our team is having some difficulties using the Composable Architecture to present a navigation stack in a way that lets each scene properly set itself up and tear itself down, and we could use some help and suggestions from more experienced folks.

Let me start by saying that our difficulties are not with navigation itself (yes, we ran into those too, thanks to NavigationLink, but we found a solution to those). Rather, they have to do with properly setting up and tearing down scene states, because our scene states have to set up and clean up resources external to the app and we can't achieve those in state initialisers because those actions are asynchronous and best handled by invoking the environment.

In a nutshell, when a parent scene is about to present a child scene, it needs to tear down its current navigation stack (since it could be presenting a child scene other than the one it’s about to present). This process must happen recursively for all scenes in the navigation stack, until the leaf scene, which simply cleans itself up. The recursion then unravels and the original parent scene can then safely present whatever child scene it was going to present originally (at which point it needs to create the child state and then ask it to do any further setup that can't be done in the state initialiser).

It’s conceptually simple but the details are complicated because the only way scenes communicate with one another is by firing actions which the scene reducers consume and process.

So, when a parent scene is about to present childA, the parent reducer's

case .presentChildA(true):

handler tells its currently presented child, if any, to tear down its part of the navigation stack. More specifically, the parent calls a function on the child state - which is known at that time - to tear down the navigation stack rooted at it). This usually involves some asynchronous calls so that function takes the child environment as an argument and returns an Effect:

case .presentChildA(true):
	state.presentingChildA = true // why we need this will be clear further down
	if let childStateB = ... { // note that there could be other blocks like this, for other scenes
                                   // that the parent is capable of presenting
		let childBEnvironment = ...
		return childBState.clearNavigationStack(environment: childBEnvironment)
					.map(ParentAction.childB)
	} else {
		return Effect(value: .continuePresentingChildA)
	}

After tearing down the navigation stack rooted on itself, the child fires an action that essentially says “I’m done”. That action is intentionally ignored by the child reducer but percolates up to the parent reducer, which then must pick up from where it was and continue on.

(in childB's reducer)

case .clearNavigationStackCompleted:
	// do nothing - the parent should handle it
	return .none

(in the parent reducer)

// there could be many of both of these, if the parent can present many different scenes

case .childB(.clearNavigationStackCompleted):
	// and now it's clear why we need `presentingChildA`. We need to remember where we were.
	if state.presentingChildA { // note that there could be other blocks like this
		return Effect(value: .continuePresentingChildA)
	} else {
		// other possibilities
	}
	
case .continuePresentingChildA:
	state.presentingChildA = false
	// continue on

As a result, the communication between scenes litters the reducers with back-and-forth actions whose only purpose is to tell another scene’s reducer that some other action was completed. Moreover, the logic for processing an action is often interrupted and split in two because it needs to wait for the child to do some cleanup. And the state has to keep track of which child presentation is currently "in flight".

None of this is business logic!

Incidentally, we already had a similar process going on to set up and to clean up scenes but we didn’t clear the navigation stack prior to every presentation, and that caused issues with deep-linking. When we got a deep link, we were simply presenting the new navigation stack without cleaning up any prior one, essentially obliterating that current navigation stack, so none of its scenes got to clean themselves up.

(before we discovered issues with deep linking)

case .presentChildA(true):
	let childAState = ...
	let childAEnvironment = ...
	state.childAState = childAState
	return childAState.setup(environment: childAEnvironment)
		.map(ParentAction.childA)

case .childA(.setupCompleted):
	// continue on presenting childA
	state.route = .childA
	return .none

case .presentChildA(false):
	guard let childAState = ... else { return .none }
	let childAEnvironment = ...
	return childAState.cleanup(environment: childAEnvironment)
		.map(ParentAction.childA)

case .childA(.cleanupCompleted):
	state.route = nil
	return .none

The above setup and cleanup still needs to happen, so the code just above needs to be integrated with the code involving clearNavigationStack.

So, to summarise, we have an explosion of actions and corresponding reducer handlers, and other ancillary state, just to signal back and forth between scenes that setting and cleaning scenes up, and tearing down the navigation stack, have started or are completed.

There has to be a better way and we would be grateful for any suggestions that can alleviate this situation.

Many thanks in advance!

[stephencelis]

Hi @wtruppel! Thanks for sharing your predicament. You might be interested in this recent discussion on navigation stacks if you haven't already read it: #1140

We also have some early, but promising experiments with the APIs, but we're pretty focussed on the Concurrency Beta at the moment, so we probably won't gave time to return to them for a little bit.

There's also a new navigationDestination API that takes a binding to a Bool, which could be useful but we haven't spent much time with it yet. Let us know if you come up with anything promising to share!

[ghost]

Hi stephencelis. Thanks for the prompt reply!

I have been following that discussion closely but

• our problems aren't with navigation itself, and
• we have to support down to iOS 14 so the new navigation APIs aren't going to help us anytime soon

Our issue is fundamentally the following: how to set up and clean up a scene whose state cannot be fully built by the parent scene at the time the parent reducer wants to present the child scene? More specifically, how to do that when the setup and cleanup of the child scene involve asynchronous side-effects?

Is there a mechanism within TCA that lets us do that without having to create a large number of actions just to signal back and forth between parent and child scenes? And also, can we do that in a way that prevents the splitting of reducer logic?

We find ourselves having to split the preparation of a child scene in two steps that are separated in the parent reducer, the first step setting up a minimal amount of state for the child and the second step continuing on after the child has done the (asynchronous) extra setup that the parent couldn't and shouldn't know anything about.

All of this has serious implications for deep-linking because a scene state is effectively not a value type, since it maintains resources outside of the app. Therefore, we can't simply obliterate the current navigation stack with a new one when a deep link happens.

Is there some piece of advice that you could give us, or a case study that you could point us to, that would help with this?

Many thanks in advance!

PS. In case you (or anyone else reading this thread) is curious, here's a toy project showing our most recent attempt to handle all of this. The project does nothing but present a navigation stack where the scenes require additional setup and cleanup. Note the amount of boilerplate and extra actions necessary just to handle all of this, with no real business logic in sight.

NewSetupCleanup.zip