For most use cases, static routes like slash protected or slash login and dynamic routes with params, like our destination page, are enough. However, Vue actually gives us the power to have much more fine-tuned control when we need it. For example, it's possible to use regular expressions when defining our route params. To see how that works, let's create an example route with a param ID.
I'll just map it to the login page so that I don't have to create a new component. Now in the browser, I can visit slash example slash one. And sure enough, we can see the login page component. Okay, admittedly, that's nothing new.
So now let's add a regular expression to the ID param that will only match numbers. If you aren't that familiar with regular expressions, let me quickly break this down for you. The slash D here matches a digit and the plus sign matches one or more of those digits. Notice we do have to escape the backslash though, in order to pass it in a string in JavaScript.
All right. So now back over in the browser, slash one still works properly. However, if we change the ID param to anything other than a number, we'll get a . Nice.
This can be a pretty cool way to keep from having to perform a request to your API in order to check for the existence of a resource. If you know your ID must be a number and the param in the URL isn't, you can just go ahead and show a . Also, using regular expressions like this, you could have two different pages map to the same path. For example, I'll request to slash one, two, three, four, or slash any other number could lead to some kind of orders page.
On the other hand, slash coffee cup or any other string that's not just a number. could route to a product description page. The paths are the same, but the makeup of the params determine which page is shown. Of course, this could handle any regular expression that you could think of, not just detecting digits.
But that was the easiest one to demonstrate. All right, besides regular expressions and route parameters, we can also create repeatable params with the plus sign. This means that no matter how many slashes I put after slash example, I'll always be routed to this page. In the browser, I can visit slash example slash one, and I get the login page.
I could also do slash example slash one slash two, and I'd still get the login page. And really, I could go on indefinitely with slash one slash two slash three, one, two, three, four, so on and so forth, as long as I desire. Also, if we look into the DevTools at the route param ID, you can see that it's an array of all the path parts after example. This could end up being very handy when you want to support a URL that could handle a list of data.
All right, I could even go on now to combine my repeatable params with the regular expression that we saw before. Now we've got a repeatable parameter that can only be a number. Pretty cool. It's also worth noting here that when using the plus sign to define repeatable params, it does make the param required for at least the first part.
In other words, visiting slash example without anything after it will give me a . However, you can make the param optional by replacing the plus sign with an asterisk. Cool. In the browser, slash example now shows the login page component.
And I can continue adding more pieces to the path if I desire. Finally, if you'd like to make the param optional without allowing it to be repeatable, you could use the question mark instead of the asterisk. In the browser, you can see that slash example slash one slash two slash three slash four now returns a four oh four. But if I go to just slash example, nice, we get our login page.
And if I go to slash example slash one, We also get the login page.