34

Is the matrix url notation the "default" to creating urls with parameters or is better to use the "old" notation with ? and &. I didn't understand it on the angular.io documentation

localhost:3000/heroes;id=15;foo=foo

or

localhost:3000/heroes?id=15&foo=foo
Johannes Rudolph
  • 35,298
  • 14
  • 114
  • 172
cpiock
  • 1,275
  • 2
  • 17
  • 44

3 Answers3

55

Matrix parameters are tied to a path segment, while query parameters are tied to the URL. They have different semantics. Use whichever one is more appropriate. (see links in "see also" below").

Maybe it's hard to tell because you always see it at the end of the URL, but this is also matrix paramters

localhost:3000/heroes;id=15;foo=foo/bar/baz

The parameters are tied to heroes. When you access the route.url, you will see this

this.route.url.subscribe((url: UrlSegment[]) => {
  let heroes = url[0];
  let heroesMatrix = heroes.parameters();
  // heroes should contain id=5, foo=foo
  let bar = url[1].path;
  let baz = url[2].path;
})

Is the matrix url notation the "default" to creating urls with parameters or is better to use the "old" notation with ?

No, both could be used, and how to use (create) them is completely different

  • matrix parameters are tied to each path segment, by passing an object after the path element in the array

      router.navigate(['/foo', { id:1 }, 'bar', {baz: 2 } ])

    Here you will get /foo;id=1/bar;baz=2

  • query parameters are created by passing the NavigationExtras as the second argument to navigate

      router.navigate(['/foo'], { queryParams: { bar: 1, baz: 2 }});

    Here you get /foo?bar=1&baz=2

See also:

UPDATE (disclaimer)

If you read the Angular documentation on optional parameters, they feel that the above semantics are not really important in regards to working with Angular. I'd probably have to agree. The semantics are more important with REST APIs.

With an Angular app, the only people who really care about these parameters are us the developer. The user doesn't care. It is not a REST API where we should stick to well known semantics. For out Angular app, as long as we the developer know how to use params (whether matrix or query), it shouldn't matter which one we use.

That being said, matrix params are less verbose to code, so personally, I'd say that using the matrix params might be the best way to go.

TmTron
  • 17,012
  • 10
  • 94
  • 142
Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
  • so if i would like to track the center changed of a map or the searchparamater of a page is it better to use query paramaters or matrix? – cpiock Oct 21 '16 at 08:55
  • queryParms should be queryParams :-) – cpiock Oct 21 '16 at 13:22
  • 3
    Matrix params are great, only be warned that Google Analytics doesn't support them. So if you are using matrix params in your URLs expect none of those params to show up in your pageViews and other reports in Google Analytics. – Kevin LeStarge Dec 20 '18 at 18:25
  • 2
    "matrix parameters are tied to each path segment, by passing an object after the path element in the array" ...wow, that's a super bizarre way to pass parameters to a function. – MattTreichel Apr 07 '20 at 15:02
4

For matrix parameters you can also subscribe to params instead of peeling them out of url.

this.paramSubscription = this.activeRoute.params.subscribe(params => {
  const bar = params['bar'];
  const baz = params['baz'];
});
dduft
  • 470
  • 8
  • 18
  • 1
    In this case `router.navigate(['/foo', { id:1 }, 'bar', {baz: 2 } ])` the method that you explain won't work, if I am not wrong. The ActivatedRoute will only resolve last param, baz=2. I checked myself. In this situation, should we use url subscription? – Mr. Mars Oct 28 '19 at 16:21
1

Both notations can be used but there is a restriction for the "old" notation. You can have only one question mark one question mark character in the URL.

With the matrix params, you can have different queries for different segments.

When is useful?

Add queries params for your auxiliaries router outlets.

For specials cases like one view with two components and each component has its own pagination information.

You want to keep that information if the user goes back to this view.

Lievno
  • 1,013
  • 9
  • 14