[Bug] Default queryParams are not getting pruned

[lvegerano]

🐞 Describe the Bug

Transitioning to from a parent route with queryParams to a child route with queryParams using the router service, fails to prune default queryParams leaving the URL in an undesired state

🔬 Minimal Reproduction

https://github.com/lvegerano/ember-qp-prune-fail

😕 Actual Behavior

Having the following routes:

• main
  • route-a

main has a queryParams

queryParams = [
    {
      labelIds: {
        type: 'array',
        as: 'l',
      },
    },
  ];

routing to main.route-a using the router service adds the serialized array brackets to route-a URL
http://localhost:4200/main/route-a?l=%5B%5D

🤔 Expected Behavior

The URL does not contain the default value of the queryParam
http://localhost:4200/main/route-a

🌍 Environment

• Ember: - 3.25.3
• Node.js/npm: - 3.25.3
• OS: - Mac/Windows WSL
• Browser: - Chrome 89

[bertdeblock]

Was this behaving differently in an older version of Ember? I was under the impression that this is intended behaviour when using RouterService.transitionTo as described in the RouterService RFC. Or is this something unrelated?

Edit: See #19492 (comment)

[lvegerano]

@bertdeblock It also happens in 3.14. Reading the RFC you are correct. Its terrible DX. How is it ok to have different behaviors when transitioning to a route? 🤯

[bertdeblock]

@mmpestorich I'm not sure I completely understand how this is related to the reported issue.
The RFC describes that RouterService.transitionTo will always include default QP values, which is the reported, but intended behaviour.

Having to use an existing array vs using a new array => If my default QP value is ['foo', 'bar'] and I set it to ['baz'] and later on I set it again to ['foo', 'bar'] (a new array) the QP is stripped from the URL. The same actually happens when using RouterService.transitionTo given the route itself does not change, though I'm not sure if the later is intended behaviour as it seems a bit contradictory.

Edit: See #19492 (comment)

[mmpestorich]

@bertdeblock I see, you're right my original analysis there is off. I didn't notice the comparison noted above is between the default and current serialized values of the query param. In which, case they should be equal strings and qp should be pruned. Sorry about that.

[bertdeblock]

Actually, after discussing this with a friend, I think that I have misinterpreted that RFC section. I was under the impression that all default QP values would end up in the URL, so not only the default values of the specified QP's via the queryParams option. So I think I'm the one who's wrong here, sorry for that! I'm guessing #19493 describes the same behaviour.

[lvegerano]

Thanks for your input @bertdeblock. The RFC certainly makes it sounds as if this is the intended behavior 🤷🏾‍♂️ .