'Is there any reason to use route.snapshot.paramMap when there is route.paramMap.subscribe?

I wonder if there is any reason to use

this.someProperty = this.route.snapshot.paramMap.get('someParam');

instead of

this.route.paramMap.subscribe((param) => 
{ 
  this.someProperty = param.get('someParam'); 
});

The same goes for queryParamMap.

In a tutorial I am following (by Deborah Kurata on Pluralsight) they seem to use snapshot by default and subscribe only when you expect the param to change while the route stays the same. But applications tend to change over time. Changes can introduce a situation where the param changes while the route stays the same. It is easy to overlook this situation.

So should it be (or is it) best practice to use subscribe instead of snapshot?

Snapshot way is shorter to write, but are there any other benefits?

I may be asking for opinions here, but I want to know if there is an official best practice.

Thanks in advance.



Solution 1:[1]

when using snapshot you get the value once and that is it, if the user changes the parameters in the url, or using navigate to same route with another parameter, you don't get the new value (unless you are reading it each time you need it)

Also snapshot is sync (versus subscribe with is async)

if you subscribe each time the value is changed you are able to read the new values.

Solution 2:[2]

When you know for certain that a HeroDetailComponent instance will never be re-used, you can use snapshot.

(source: snapshot: the no-observable alternative angular doc )

Choosing between the snapshot paramMap or the observable paramMap is based on your app's expected navigation scenario. Only for certain cases, component reuse can be achieved with the usage of the observable paramMap way. Apart from that, the observable paramMap (async subscribe) doesn't seem to bring any benefits.

So just read the snapshot property and handle the variable, it's needless to handle an observable here. Play with observables only when it brings benefits. details

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Martijn
Solution 2 tinystone