To get access to route and query parameters in Angular, you need to manually parse the
While this is not hard, it can quickly bloat your codebase.
Until Angular provides a better and typesafe way to access route and query parameters, you can use zod to make it easier.
First, let's see how we can access a route parameter without zod.
Let's use a route that contains an
id parameter, which should be a number.
This looks as follows:
To access the
id parameter, we need to inject the
ActivatedRoute instance and then read the
id property from the
Doing this works but it's not typesafe, as you can see
id$ has the type
To make it typesafe, we need to manually verify and parse the
Let's see what that looks like:
id$ has the type
Observable<number>, which is what we want.
But contains some boilerplate code.
Instead of manually parsing the route parameters, we can use
zod to do the heavy lifting for us.
So let's do that.
The first step is to define a zod schema for the route parameters. Then, we can use the schema to parse the route parameters.
In the example below I've created the schema
route which contains the
To parse the route params, we can use the
parse method of the schema.
Sadly, this does not work yet. Because all route parameters and query parameters are strings, the above code results in a zod parsing error.
And... we're back to square one because we don't want to manually parse the route parameters.
We could use the
transform method, but this doesn't validate if the
id is a number.
For example, if the
id in the route is a string, then the following code returns
Luckily, in zod v3.20, you can use the
coerse method to quickly transform the value of a primitive.
The end result is that we can now easily access route and query parameters from an Angular route.
We can do this in a typesafe way, without having to manually parse the route parameters.
Keep in mind that this throws an error if the route parameters are invalid, in our example, when we
id parameter can't be parsed to a number.
In this case, we end up with the same error as before, which is a good thing because it means that we can't accidentally use an invalid route parameter.
I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.