Feature Based Routes

feature-u recommends that you consider using Feature Routes for your routing needs ... via the feature-router extendable Aspect (packaged separately).

You may be surprised to discover that feature-u recommends it's own flavor of route management. There are so many! Why introduce yet another?

Obviously feature-u does not dictate any one navigation/router solution (the recommendation is even in a separate package). You are free to use whatever route/navigation solution that meets your requirements.

• You can use the recommended feature-router
• You can use XYZ navigation (fill in the blank with your chosen solution)
• You can even use a combination of Feature Routes routes and XYZ routes

Why Feature Routes?

The big advantage of Feature Routes (should you choose to use them) is that it allows features to promote their screens in an encapsulated and autonomous way!

A key aspect of any feature is to have the ability to inject itself into the app's process autonomously (as much as feasibly possible). This may even include UI Component injection (depending on your philosophy).

How do Feature Routes work?

Feature Routes are based on a very simple concept: allow the application state to drive the routes!

It operates through a series of feature-based routing functions that reason about the appState, and either return a rendered component, or null to allow downstream routes the same opportunity. Basically the first non-null return wins.

In feature based routing, you will not find the typical "route path to component" mapping catalog, where (for example) some pseudo route('signIn') directive causes the SignIn screen to display (which in turn causes the system to accommodate the request by adjusting it's state).

In other words, you will never see application logic that re-routes to a signIn screen after checking to see if the user is authenticated. Rather, the appState is king! If the user is NOT authenticated (based on the route's analysis of the appState) the SignIn screen is automatically displayed ... Easy Peasy!

Depending on your perspective, this approach can be more robust and natural, but more importantly (once again), it allows features to promote their own screens in an encapsulated and autonomous way!

How do I proceed?

This discussion is obviously merely an introduction. There is more to Feature Routes that we haven't touched on. Should you choose to use them, please refer to the feature-router docs.