Express JS — Routing with Nested Paths

Photo by Julia Kadel on Unsplash

Do you find yourself building out a complex and vast routing system with the same parameters? Don't you wish there was an easy way to have the single parameter passed into your controller? Fear not! There is a simple way!

The Nested Router.

While foraging in the wilds of Google, trying to find an effective means to create a path structure that would simplify my paths and maintain a key parameter in the same go, I found this gem. The article was both extremely helpful and rather confusing for someone who had the basics of Routers under their belt. So I decided to offer a leg up on deciphering it.

As a disclaimer, I say the code samples I'm using are from a personal project and is a work in progress, be patient with me.

For anyone familiar with Express JS, the image below should make sense.

Express workflow

If not, here are some resources to look over before we dive deeper:

Using middleware

https://scotch.io/courses/using-react-router-4/route-params

Okay, so now that know what's up, let's start creating some paths.

You decide it makes sense to do the hard work of creating everything, and then you realize your paths are a complete mess. You have about eight different routes imported into your main index.js, and every single one of them has the same parameter. This seems a little messy for a file that should really be a holding point. So how the hell are you going to clean up this madness:

The file you are trying to main

Is it easier to have your other routes as a kind of breakpoint? You would just have to go through one main router and branch off from there. That would be so much easier on your brain! That is what we are doing with this process.

You have your main setup, but what does that main router look like?

What is going on?! This doesn't make a lick of sense from what you can see in your routers. Why is there a use statement in there? Why does it say 'start' instead of 'router'? What is that thing inside Router at the top?

Let's break it down from the top. We decided it was confusing to use 'router' for everything since you have too many of them; let's make it less confusing for ourselves, but name it something that helps us remember our goal. That's pretty easy, but the thing inside Router?

mergeParams! It's your new best friend.

What does that actually mean? This is a way to call on that param you established in that first get in all your subsequent routes. So since you have your param already established, once you move to your following child route, you will still be able to access that param. But it's already stored; why would I do that? This makes it so there are no longer issues with naming conventions you may have previously used and forgotten about.

So in the example case, it makes a req.params.username in my user file; it will be the same as what I put in when I was just trying to look at the file we are currently in. This creates a standing reference point.

What does the url look like? http://localhost:4001/LuV2eat

That's all nice and all, but how do I actually get to that child element?

That is where use comes into play. Just like use in your main index.js, you are creating a path, but since you have imported your other router from this path, this will not be the starting point for those paths.

Here is the important part, though,

your first nested, child, router

you need to make sure you have that same mergeParam set to true inside your new child router as well, or it will not have that same standing reference, and you will be having a very bad day and not understand why that param stopped working quite right.

So what does your beautiful new path look like?

http://localhost:4001/LuV2eat/info

Isn't it beautiful? AND IT WORKS!

Returned from your user parameter

I am sure this seems like a lot of steps to take when you could just write out your paths and get the same result.

Here are things I love about this:

1. I can go to any other route listing in the main router folder, and it will automatically already have the username I have based my queries on inside my controller.
2. It is one less parameter I have to worry about passing in. It has established itself, and I don't have to keep re-stating it because it will remember! Why you? You already told me that! Now I just need to worry about passing you the id of that list item I need to reference.
3. My routers themselves can be more specific and streamlined to what I really need to work on.
4. I have to stop myself from having conflicts with the req.params name I came up with.
5. If I wanted to, I could create further levels of specificity. For example, say I had another set of parameters that were also always going to be the same went I get to a specific point; I could create another level like this to resolve that issue, another holding spot.

I think this process has a lot of potential, especially for scaling.

Well, I hope you found this useful!

As a heads-up, I do treat my posts as living documents and try to come back and update them as needed. If you have any additional input on recent changes to this process, you would like to share, please feel free to comment!