[ Nesting Routes ] Some Possible Solutions

Hi ! My main ( and only ) problem, is that nesting routes seems not really consistant

let’s say I have that kind of app structure

/dashboard => Dashboard stuff /dashboard/posts => ListOfPosts /dashboard/posts/add => AddPostForm while keeping ListOfPosts /dashboard/posts/:id => EditPostForm while keeping ListOfPosts

/dashboard/posts/add =>

<Switch>
  Dashboard
  <Switch>
    Posts
    <ListOfPosts />
    <Switch>
      AddPostForm
    </Switch>
  </Switch>
<Switch>

The thing is that if I name /dashboard as DASHBOARD and /dashboard/posts as DASHBOARD_POSTS, and then I go to DASHBOARD_POSTS, the matching of the first switch will require additionnal logic to keep it on the right component

I have the feeling that i should treat all my segments as variables and have that kind of routemap /dashboard(/:1)(/:2)(/:3)

but this would not be consistant as in the future I could add /dashboard/backup or other things which would need another kind of logic…

I may have misunderstood the way to do things though

[faceyspacey]

Also keep in mind, there is two ends of the spectrum:

• app specific components that match based on simple reducers like the page and sidebarOpen reducer
• and advanced React Router style components that match based on non exact paths, thereby enable nesting.

You can make things in between if u want. Ie a simple reusable route component.

Here’s an example for exact matching: u can store in each route on ur routes map a key called “component” which has the actual component class/function to use. And then you simply get it in a parent component like this: routesMap[currentRoute.type].component.

If u want nesting, u could order ur routes so that less specific ones are first and loop through them until one has a path whose indexOf is 0 when compared to the path passed to your custom route component. That’s a poor man’s nesting. Now that said it isn’t necessarily, as u can write any custom logic here to choose the component. A nice way to go is to make a function that takes an action type and perhaps a second arg for kind, ie to indicate u want the correct list.

So there’s a A LOT of options. The takeaway of this comment is that u can reuse the routesMap over and over again and add as many arbitrary key/vals to each route as u want.

[faceyspacey]

A lot of people have come with this issue. It’s primary a result of coming from React Router where there is more automation at the component level. So we may either provide components in the future or find some other automated solution, or possibly just let it be.

That said, it’s easy to overcome and you will be more in control of your app in terms of explicitness as a result of it. The explicitness will inevitably come in handy as your app grows and you need to customize for new scenarios that don’t fit the automagic capabilities standard to React Router style components. Basically what I’m about to outline is the truly professional state-driven way to craft your app.

Here’s how you do it:

For one you have to think: everything that goes through RFR hits Redux. So that means Redux has knowledge of every route hit and its params as payloads; and it can conveniently switch over types. Redux is powerful. Anything you can do with Redux, you can do. So the primary thing is related POST actions need to trigger a reducer so that its value is something like: currentList === 'posts'. And then for the form you might have currentForm === 'post'. Now that said, you could just have a page reducer or model reducer which stores a string corresponding to the name of the current page or model. Then you could have reducers like showList === true or showForm === true, just as you might have sidebarOpen === true or tabbarVisible === true.

You can simplify it all down to one page reducer or get more complex, depending on your needs.

Now that said, you can use optional params. They are used the RR4 way with :foo? instead of the RR3 way with (/:foo). That will essentially allow you to have less types to switch over in reducers, but at the expense of essentially switching over payload params in your thunk to perform specific thunk actions. I.e. because now you would have less thunks. That decision is up to you. The RFR way there is not to worry about adding more types to switch over in reducers. It’s healthy explicitness that will keep you both aware and in control of how different portions of your app affect each other, whereas before Redux apps were prone to inconsistent states because of so many setter/getter style actions.

Essentially the contract created by the fact that some actions correspond to routes results in less actions overall. You have to think that browser/back buttons (or deep-linking in React Native) need to be able to setup the entire app state based on a route. So the contract forces you to make “fatter/smarter” reducers that set themselves up and tare themselves down based on these actions. So you will have less actions overall, but your individual reducers will have listen to more of them to guarantee the correct state. And this is far better than before where you end up doing stupid things like dispatching 3-5 consecutive synchronous actions to create the correct state when a user arrives at important URLs. The easiest example is how easy it would be for a sidebar to end up in an inconsistent state where it was incorrectly open of closed because it wasn’t listening to the URL as intelligently as more standard components that make up your React Router style component route tree. Your components can kind of just sit around and be even dumber, while you move even more business logic to where it belongs: your reducers, aka your domain logic.

Otherwise, make sure to check the top of the readme–a lot of new things have been added, including support for optional params. That may give you some ideas if you’re hellbent (like some people seem to be) on reducing the # of types switched over in reducers 😃