Getting Started with Express

2.2 Custom Middleware Based on Route Parameters

All the middleware and route functions and other layers that we discussed in the previous screencast existed in previous versions of Express. However, Express 4 also brings us a new type of middleware that is based on route parameters. Now we haven't looked at route parameters yet, so let's create a basic request here that uses a route parameter. Lets say we want to get slash name slash colon name. Now, that slash colon name there is the router parameter. When we have a colon here it makes this token here a placeholder for some other value In the route. Basically, what this means is that we can have slash name slash anything and then colon name allows us to get a hold of whatever that value is. For example here, we can do it with response.send and we'll say your name is, and we can use + request.params.name, which is the object on which any of these root parameters will be. And this is of course part of the way that we customize what exactly is displayed on the page. So if we go to localhost3000/name/andrew you can see we have your name is Andrew. You can set up what your name is Jack. You can see it has Jack. If I say your name is John Doe, you can see it says, your name is John Doe. So that is a route parameter, but I mentioned that new in express four is a way to run middle ware based on those parameters. And the way to do this is with app.param. The first property that we give to param is the name of the token that we want to work with. The name in this case is name, and this name here matches this value right here. If we change this value to say apples, then this value here would be changed to apples as well. So the first argument here is the name of the parameter that we want to match in any of the following routes. Of course when you use app.param, it means you probably want to do something with that param value before we actually run the route with this parameter name. So it's important that you put your app.param call above the route that uses that parameter because remember, requests are processed from top to bottom. So if you want this to be processed first, it has to go above. Then of course we have a call back function, and as you might guess, we have the request, the response, and the next objects. However we can get another parameter here, and that is the value of the parameter that we are capturing from the road. So in our case I'm going to call that name, although of course you could call it whatever you want. But this value here will match the token in the route below with the same name as the one we passed in as the first parameter. So now in here, what we want to do in this case, let's say request.name equals, and we're actually going to modify the request object. We can set it equal to name. I'll get the first character from the name, and I'll say toUpperCase, and then we'll add name.substring, cutting it from the first point there. And then of course we'll call next. So all this is gonna do is this it's gonna capitalize the first letter of the name, and assign that name to request.name. So that we can change down here to request.name because we've assigned it in a previous piece of middleware. So now if you come back here and if I refresh this page notice that J in John Doe is now capitalized. If I go back to Andrew, you can see that it's once again capitalized the A in Andrew. Now what I've done here is a very simple example, however where this could really be useful would be getting a username from a database. So, for example, if a users database, you might say findOne, and you wanna find it where the username is equal to that name, right? You might have something like this, and then you have a callback here, where you get that user, and then in here you might say request.user equals the user object and then you go ahead and call next. And so you can go ahead and get a user object every time you have a route that has that name in it. And the beauty of this is is that it's almost like a more nuanced version of the app.all. So you could do something like this with app.all, if every time you wanted to get, post, put or delete a user, you had the very same route, name/username. However, that could just be the get route, and when it comes to doing an update, you might have app.put where you have /name/:name/edit, or something like that, right? Or delete would be /name/:name/delete. So in these cases, using an app.all would not really work because you have three different routes that you need to run a certain piece of middleware before. But of course you can't use app.use because there maybe be routes without name and then you wouldn't have any name to find the user by. And so for this reason I think app.param is a really nice addition to express because it allows you to run something based on only part of your route. Of course, you could have this user.findOne code in every single one of these routes, however, I think the idea of breaking your code into smaller, manageable pieces that make development easier is one of the main mantras of the express framework.