Do you find yourself building out complex and vast routing system that takes in the same parameters ? Don’t you wish there was an easy way to have the single parameter passed in to 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 as someone who had the basics of Router under their belt. So I thought I would offer a leg up on deciphering it.
As a disclaimer, should say, the code simples I’m using are from a personal project and is a work in progress, be patience with me?
Anyone who is familiar with Express JS, the image below should make sense.
If not, here are some resources to look over before we drive deeper:
Express is a routing and middleware web framework that has minimal functionality of its own: An Express application is…
Okay, so know we know you know what’s up, let’s start creating some paths.
You decided it makes sense to do the hard work of creating everything, then your 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 just be a holding point. How the hell are you going to clean up this madness:
Wouldn’t it be easier to have your other routes as a kind of break point ? 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 set up, but what does that 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 way ‘start’ instead of ‘router’ ? What is that thing inside Router at the top?
Let 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 what our goal is. That’s pretty easy, but the thing inside Router?
mergeParams! It’s your new best friend.
What does that actual 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 your move to your next 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 issue with naming conventions you may have previously used and forgot about.
So in the example case, it I make 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 create a standing reference point.
What does the url look like? http://localhost:4001/LuV2eat
That’s all nice and all, but how to I actual get to that child element?
That is where use come into play. Just like use in your main index.js, you are creating at path, but since you have imported your other router from this path, this will not be starting point for those paths.
Here is the important part though,
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?
Isn’t it beautiful? AND IT WORKS!
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:
- 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.
- 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 already told me that! Now I just need to worry about passing you the id of that list item I need to reference.
- My routers themselves can be more specific and streamlined to what I really need to work on.
- I have stop myself from having conflicts of req.params name I came up with.
- If I wanted to, I could create further levels of specificity. Say I had another set of parameters that were also always going to be the same went I get to 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, and if you have any additional input of recent changes to this process you would like to share, please feel free to comment!