Nested flows showing odd (popping) behavior on sub flows when pushing new screen on parent flow

[dannyhertz]

With a current flow as such:

[ScreenA -> [ScreenB -> ScreenC]]

And trying to push a new screen onto the parent flow, we would expect the updated flow to look like:

[ScreenA -> [ScreenB -> ScreenC] -> ScreenD]

But it seems to pop the child flow back to its root like so (and kills the animation to ScreenD as well):

[ScreenA -> [ScreenB] -> ScreenD]

Playing around with the debugger the child flow seems to trigger this resetting:

        set: { isShowing in
          guard !isShowing else { return }
          guard allRoutes.wrappedValue.count > index + 1 else { return }
          allRoutes.wrappedValue = Array(allRoutes.wrappedValue.prefix(index + 1))
        }

Any ideas why this is happening? Is there any documentation/examples on setting up sub-coordinators? Is what I'm attempting to do not allowed?

Thanks!

[johnpatrickmorgan]

Hi Danny, thanks for raising this issue. I'm afraid it's not possible for a parent coordinator to push new screens on top of a child coordinator that is itself pushing screens. As you've noticed, the parent coordinator would try to push from the root screen of the child coordinator (ScreenB in your example), which would cause the strange behaviour you observed.

The FlowStacks README includes a caveat about this, but I neglected to include it in the TCACoordinators README:

When [using child coordinators], it is best that the child coordinator is always at the top of the parent's routes stack, as it will take over responsibility for pushing and presenting new screens.

I'll add a similar note to the TCACoordinators README - thanks for bringing that to my attention. I hope this limitation doesn't cause you problems.

[dannyhertz]

Thanks for the quick response @johnpatrickmorgan! Yeah, I saw that comment but a bit confused with some of the wording, specifically "top" of the stack.

So quick follow up, if this isn't allowed, what are valid uses of child coordinators? Are we limited to pushing a single child coordinator and not pushing anything else unless we first pop that child? Can you have multiple child coordinators (in any orientation) in a single flow?

Thanks again. Your libraries are super duper helpful.

[johnpatrickmorgan]

Yeah, I saw that comment but a bit confused with some of the wording, specifically "top" of the stack.

Ah right sorry, I tend to think of the array of routes as a stack, so the current screen is the 'top' of the stack. But I should definitely try and explain that limitation more clearly.

So quick follow up, if this isn't allowed, what are valid uses of child coordinators?

I think the way to use child coordinators with this library is as you describe: pushing/presenting a child coordinator and then allowing that child coordinator to take responsibility for pushing/presenting screens, until it's time for the parent to pop/dismiss the child and take back responsibility. The child coordinator itself might push a child coordinator of its own, so you could have a chain of multiple coordinators in that pattern. And a coordinator might have multiple possible child coordinators, but could only show one child coordinator at a time. I'll try to incorporate an example of using child coordinators into the example app and improve the documentation around that.

Thanks again. Your libraries are super duper helpful.

Thank you! 😊