State-driven navigation tools within the context of a hyper-modularized codebase

[acosmicflamingo]

I'll preface this by saying that the new navigation tools are light-years beyond what I'd ever expect from TCA and am absolutely floored by how powerful and amazing it is!

The only question I have that I don't think has been addressed (and probably because it's the smallest corner-case in the world) is how we can achieve the same behavior of deep-linking outside of the app's root view if the new tools seem to assume that the stack state belongs in only one place, and that is the RootView. If I created a mock app whose "RootView" really is "SettingsView", that SettingsView is not going to have a StackState property because it doesn't need it. However, if I created a SettingsPreview app and wanted to test out navigation within SettingsPreview, now there is nothing in its state that would allow me to push and pop subviews like before.

With an example, I believe that in one of the videos, it was discussed that the benefits of tree-based navigation is being able to do something like:

public class RootViewController: UIViewController
  let store = Store(
    // Deep-link for testing app
    initialState: AppMain.State(
      destination: .home(
        .init(
          destination: .settings(
            .init(destination: .whatsNew(
              .init(selectedSegment: .none)
            ))
          )
        )
      )
    )
  ) {
    Root()
  }
}

With the new navigation tools, it'd look something like this:

public class RootViewController: UIViewController
  let store = Store(
    // Deep-link for testing app
    initialState: AppMain.State(
      path: StackState([
        .home(),
        .settings(),
        .whatsNew()
      ])
    )
  ) {
    Root()
  }
}

This works of course because Root.State for RootView would have a path: StackState property in there. My question is, how can this same behavior be achieved outside of Root.State? If it can't be achieved, then I suppose that means isowords preview apps are not going to have the ability to push or pop anything from the navigation stack?

[mbrandonw]

This is something that has been discussed a few times in episodes, and it is covered in some of the documentation. There is a balance between coupling and decoupling features. Decoupling sounds like a good idea, and nav stacks help with it, but it also comes with some downsides. You just need to figure out which aspects of tree and stack-based navigation are important to you and make the choice yourself.

But, at the end of the day you can also find work arounds for navigating from deep parts of the app. For example, the settings feature could post a notification that the root listens for in order to update the navigation stack.

[acosmicflamingo]

Thanks! Great documentation; definitely lays out my thoughts!

Almost seems like what I thought was a problem is actually a great constraint. Perhaps the decrease in compile-time for an app with decoupled components would be great enough to render the preview apps completely useless. In addition, it seems like it makes the most sense for integration tests to happen within the RootFeature module. The inert behavior wouldn't be a big deal since that would be tested during the integration tests. If you agree, I could just mark your comment as the answer and we call the discussion a day :)