How to clear queryParams?

I have a login screen that have 2 different UI: Normal login and Quick login. And I also have two button

{{#link-to 'login'}} Normal login {{/link-to}}
{{#link-to 'login' (query-params isQuickLogin=true)}} Quick login {{/link-to}}

For quick login button, I add a query param ‘isQuickLogin’, which is also declared in the controller.

If I click ‘Normal login’, it will navigate to login screen without param: http://localhost:4200/login

If I click ‘Quick login’, I will get the param, then I can render something for quick login: http://localhost:4200/login?isQuickLogin=true

However, If I click ‘Normal login’ again, the param is back. http://localhost:4200/login?isQuickLogin=true

That is not what I want, I have not add param for Normal Login, why did I get that param? Seems it is cached in somewhere, but I can not find it in the guide. I am referring to:

How to clear the query param? Can anyone help me? Thanks

You have to manually set it. Since Controllers are singletons the queryParams stay what the my were. I would suggest the following:

{{#link-to 'login' (query-params isQuickLogin=false)}} Normal login {{/link-to}}
{{#link-to 'login' (query-params isQuickLogin=true)}} Quick login {{/link-to}}

You can think of queryParams as part of the route definition in the same way dynamic segments are.

Thx, yes that works. But there are many login entry point in our project and many teams work on login. I can not ask them to manually set the flag one by one.:sob: The thing is there are many Normal Login entry, but only one Quick Login entry point, is there any other better solution I can pass parameter to login controller?

You could use resetController to set the isQuickLogin back to false when leaving the login route?

Yes yes, I agree with this.

export default Route.extend({
  resetController(controller) {
    controller.set(‘isQuickLogin’, false);
  })
});

Though I would caution that perhaps queryParams is not the best fit in this case. Maybe a different route or possibly a component that knows how to construct the link-to appropriately?

In any case the fast solution is what @raytiley suggested.

Let me provide more detail: I have two different route: ‘main’ and ‘login’, the login entry point are in ‘main’ route.

What I want to do is pass a param from ‘main’ route to login controller when click the quick login entry. Is there any other solution for this case?:thinking:

Thx, I agree with you, but my issue is login controller got wrong param when enter login route.:frowning_face:

Hi, I am running into this too. It’s pretty frustrating cause the work around is to add the parameter to all calls. I would expect that if I don’t send a query param, I don’t get that query param. I would not expect the route to save the query param.

Routes saving query parameters is a result of controllers (where the query parameter values actually live) being singletons (much like services). One of the best ways to handle this if you want the query parameters cleared when leaving a route is to set the query parameters back to default values when exiting the route: Route - 3.21 - Ember API Documentation

I understand that, and unfortunately, that’s what we’ll be forced to do. But I think the use case where you want to preserve queryparams is few and far between.

Is there any reason that Ember couldn’t just stop preserving them? Don’t store them in state, or automatically clear them for us. At least make that behavior configurable so we’re not forced to manually clear every query parameter that could ever be called for a page. Imagine if someone decided to have a dynamic set of queryParams too… that would be a nightmare to manage.

I think preserving query params is a sensible default, but I agree it would be nice if there was an easier way to clear them. Really I think the problem is that query params have long been in need of some TLC and I believe they are being prioritized for a redesign in the near future. In the meantime you can check out ember-query-param-service. Not sure if it will help with your use case specifically but it might make managing QPs a little easier.