Question: Is it possible to change query params without reloading route?

I’ve got a strange use case - I’ve got a checkout form where user can select a product and enter a discount coupon. Now, whenever user changes a selected product, or enters a coupon, I’d like to persist this info in query parameters, so that when user reloads the page, or sends its url to someone else, they will see the page in exactly the same state. However, if I use navigation.navigate (or history.push) to change query params, it triggers route change and executes routing code again and I’d like to avoid that. Angular 1.x router has reloadOnSearch option that could be set to false, to avoid reloading route on query params change. Is it somehow possible to do the same thing with navi?

[jamesknelson]

I’ve come across a similar problem so I definitely want to find a good solution for this. The issue is that HTTP redirects on the server can’t pass state through, and I want the API to work across both SSR and the client.

I have a few ideas about this, just need to find the time to put them into a proposal or some code.

[szimek]

One more use case 😉

We support PayPal payments and we need to pass a failure url that PayPal will redirect to in case of, well, failure. In our case the failure url is the same checkout page, where user initiates PayPal payment. We only append a query param with an error message to it and PayPal appends a token query param. In our old Angular app, we checked for these query params on page load, showed an error message and removed them. This way when user would e.g. reload the page, they wouldn’t see the same error message again. Because this logic happened in a component, we could already preselect PayPal as preferred payment when these query params were present.

In navi, it looks like I can redirect to the same url without these query params, but then I won’t know that user had PayPal selected. Unless it’s possible to pass state to redirect function, just like to navigation.navigate? Not a big deal, but would be useful to support this use case.