1. 6
    Define and read query parameters with the Angular router
    2m 50s
⚠️ This lesson is retired and might contain outdated information.

Define and read query parameters with the Angular router

Share this video with your friends

Social Share Links

Send Tweet
Published 7 years ago
Updated 3 months ago

An Angular URL can be structured into segments, each of which is formed by its path and a series of additional information such as parameters, query parameters and fragment. Query parameters are a way to provide useful data to components, with the particularity that they are shared across many activated routes and therefore accessible from multiple component. In this lesson we will learn how to define and read a route’s query parameters.

Instructor: [00:00] Here, you can see a very simple routing configuration, which is defined in this people routing module. Whenever our browser URL points to this people/pathOne, our person detail component will be visualized.

[00:12] Now, one of the various ways of passing data via the URL to our person detail component, or generally to our router components, is by indicating our query parameter. Now, a query parameter is usually added to the browser's URL bar by a question mark. Then, for instance, we could say showChild equals true.

[00:32] As you can see, even though we specified a different kind of URL by indicating that query parameter, our personal detail component still works, and it should visualize correctly. That's because query parameters can be added arbitrarily to any kind of URL we define.

[00:47] We don't have to change our routing configuration for adding those parameters. For reading those, we can simply jump into our person detail component in this case. We need to get hold of the activated route object, which needs to be imported here always from Angular router.

[01:07] Then either in our construction or also in our ngInit, we can access those query parameters. We do that by accessing activated route, query params. It is an observable, so we can subscribe to it. Let's get that data printed out.

[01:22] If we open up the console, we see here the log statement. You can see we get an object where the property matches basically here the key in our query parameter and the value below. Afterwards, it is the value we specified here.

[01:37] These are always strings. Regardless of whether you pass a number, a Boolean, or whatever, these come in as strings. Make sure to always convert them, if you need to.

[01:46] Now that we get the data, we could simply say something like showChildren. False is the default value. Then we can go inside here say something like, diff and if. Then here below, we obviously need to set this to true showChildren.

[02:11] We can see now it gets loaded properly. If we change this to false, then it gets hidden, as it also gets when you don't specify anything. As always, if you know that your routed component gets reloaded every time your routing changes, we can also bypass the observable registration and directly access the snapshot.

[02:31] We access the snapshot, query params, show childs. We need to properly assign this also. Obviously, in a real-world scenario, it would then use this information, for instance, to query further data from your server.

BHRUGU DESAI
BHRUGU DESAI
~ 5 years ago

Can you guide or provide link to any informative read on

  1. using snapshot vs observables, and why do you choose one over the other?
  2. is this angular specific best practice or javascript specific best practice.

thanks

Juri Strumpflohner
Juri Strumpflohnerinstructor
~ 5 years ago

Hey, the main difference is that snapshot is a "resolved" value, while the other options are Observables and thus may provide new values over time. When would that be useful? Well, for instance if your component remains active while the route changes. In those cases you need to subscribe to the observable, to get the new route values and refresh your view accordingly.

For instance, if you have a list of data and whenever you click an entry you navigate to the detail view, then you could rely on the snapshot, since the detail component gets re-created every time you navigate to it. However, if you have some kind of "master-detail" navigation, where you have a list of data and beneath it the detail refreshing based on the list entry the user clicks on, then you need to use an observable. The reason is you need to get notified whenever the URL changes, s.t. you can read the new id and fetch the data accordingly. This video lesson illustrates that scenario.

In general I'd say it's best to use the observable, because often your not sure where your component is being used.

Hope that was helpful.

Pedro
Pedro
~ 5 years ago

According to docs: """

Two older properties are still available. They are less capable than their replacements, discouraged, and may be deprecated in a future Angular version.

params—An Observable that contains the required and optional parameters specific to the route. Use paramMap instead.

queryParams—An Observable that contains the query parameters available to all routes. Use queryParamMap instead. """

Slo Cha
Slo Cha
~ 3 years ago

Thanks, Juri, for that helpful response as to why one would choose to use the snapshot over the observable.

Markdown supported.
Become a member to join the discussionEnroll Today