Navigating through different levels

[DavidKmn]

How could we utilise the package to route through different levels of navigation of different feature modules. Let's say for example we have:

A link like my-app-name://home/info/helpCentre?helpTicketId=1

// Feature module: AppFeature
enum AppRoute {
    case discover
    case home // HomeFeature
    case settings
}

// Feature module: HomeFeature
enum HomeRoute {
    case similarProducts
    case info // InfoRoute
}

// Feature module: InfoFeature
enum InfoRoute {
    case termsAndConditions
    case helpCentre(helpTicketId: Int)
}

The idea here is we would not want to expose these routes to the outside and they would be internal to the module. We would therefore want to I guess parse just the required info and pass the rest to the next module. For example we parse off the path related to AppRoute then pass the rest to HomeRoute, HomeRoute then parses just enough to identify that it needs to present InfoFeature and passes the rest to InfoFeature which in turn presents the final screen.

[mbrandonw]

This is definitely possible. You'll want to nest your routes:

enum AppRoute {
    case discover
    case home(HomeRoute) ⬅️
    case settings
}
enum HomeRoute {
    case similarProducts
    case info(InfoRoute) ⬅️
}
enum InfoRoute {
    case termsAndConditions
    case helpCentre(helpTicketId: Int)
}

And then you can nest your routers:

let infoRouter = OneOf {
  ...
}

let homeRouter = OneOf {
  Route(HomeRoute.info) {
    Path { "info" }
    infoRouter
  }

  ...
}

let appRouter = OneOf {
  Route(AppRoute.home) {
    Path { "home" }
    homeRouter
  }

  ...
}

And that allows you to put the route enum and router into a feature module.

We demonstrated this in detail in the 2nd part of our modularization series: https://www.pointfree.co/episodes/ep172-modularization-part-2

[DavidKmn]

I see, the question then becomes where do these routes live and where do the respective routers live, in the composition root?
Let me be more concrete, lets say we have an app that is fully modularised by features (say similar to isowords in terms of structure). The 2 things we want to achieve is internal deep link routing (e.g. one feature module can call a deep link to route to another feature module) and external (called from outside the app). So using the example above where do you suggest we keep the routes and the routers?

[mbrandonw]

I think this is a much bigger discussion that goes well beyond this library's responsibility. This library is really only focused on the issue of turning URL's in route values, not how one then interprets those routes in a real application.

Perhaps others have opinions that they would like to offer, but you may want to also try asking in a more general purpose forum to get better feedback.

[lukeredpath]

@DavidKmn generally, your feature dependency graph will form a tree unless you go to great lengths to completely decouple modules from their parents and avoid this structure. I'm not sure that there is much benefit to this so I'm going to focus on the typical structure where you have something like:

App
|----Feature One
|                 |
|                 -----------Feature Four
|
|----Feature Two
|
|----Feature Three

And so on.

In this case, each feature can be responsible for owning it's own routes, which it exposes as a public type.

Each route is embedded in the parent's routes as an associated value on a case, just as Brandon recommended above.

Features do not need to know anything about their parent or the context those routes are being used in but parent modules always know about their child modules.

What you end up with is something like:

// In your App module
enum AppRoute {
  case featureOne(FeatureOneRoute)
  case featureTwo(FeatureTwoRoute)
  case featureThree(FeatureThreeRoute)
}

// In your FeatureOne module
enum FeatureOneRoute {
  case featureFour(FeatureFourRoute)
}

// In your FeatureTwo module
enum FeatureTwoRoute {}

// etc...

The router parsers can also live alongside each route type in their respective module.

[DavidKmn]

Thanks for the response @lukeredpath, I completely understand this use case. Actually I a more focused on the full decoupling of the feature module graph case. So some modules in the project are fully decoupled and injected into parents at a composition root level. Therefore routes living directly in the feature does not work unfortunately, hence I was looking for approaches out there.

[lukeredpath]

I've not really done much with his kind of approach before, but I guess one approach would be to not use an enum to model your routes and consider some kind of generic struct approach which would let you compose your routes together without them knowing about the concrete implementations.