router.urlFor does not serialize nested query params

[snewcomer]

🐞 Describe the Bug

this.router.urlFor('route-name', {
  filter: {
    user: {
      name: 'yay!'
    }
  }
});

Produces a url of ?filter=%5Bobject%20Object%5D.... Same issue with this.router.replaceWith and probably other methods

🔬 Minimal Reproduction

See tests here - https://github.com/emberjs/ember.js/blob/21bd70c773dcc4bfe4883d7943e8a68d203b5bad/packages/ember/tests/routing/router_service_test/urlFor_test.js

😕 Actual Behavior

?filter=%5Bobject%20Object%5D

🤔 Expected Behavior

?filter=[user][name]='yay!'

🌍 Environment

• Ember: -
• Node.js/npm: -
• OS: -
• Browser: -

[snewcomer]

There are some other considerations - generating nested query strings can be done many different ways and exploring a solution requires that we settle on "one" of the ways to ensure we don't go breaking users.

e.g. a nested filter

?filter[make]=honda&filter[model]=civic
?filter=[make]=honda&filter=[model]=civic
?filter.make=honda&filter.model=civic

e.g. nested array filter
?a[0]=b&a[1]=c
?a[]=b&a[]=c
?a=b&a=c

Note - libraries like qs have taken stances on certain patterns. We can glean what to do from them but in no means is it the "correct" way.

[NullVoxPopuli]

wouldn't you need to setup a (de)serializer setup for this? because (as you mentioned) there is a couple different ways backends expect nested data to be formatted and we can't dictate "one way" to do this. I think providing a default makes sense as it'd be nicer than [Object object], but we'd need a way to switch formats.
Like, if someone needs:

?filter.make=honda&filter.model=civic
?a.0=b&a.1=c

(nice car choice, btw)

[snewcomer]

We would. That is why qs seems like a great library to implement our needs. It has a whole host of configuration options that we can then saliently expose to the user via our apis.

[NullVoxPopuli]

qs, specifically is 9.6 kb (after min+gzip): https://bundlephobia.com/package/qs@6.10.3
I'd want something a bit smaller if built-in 😅

[NullVoxPopuli]

This is 2.3kb (after min+gzip): https://bundlephobia.com/package/query-string@7.1.1
but,
if I don't need object and array parsing, I wouldn't want to pay this cost and make my users pay this cost.

Though, when we get to a point where we can svelte away unused parts of ember, maybe I'll be less 🤷 about adding whole libraries

[sukima]

praise: I agree, [object Object] is not ideal and having a better solution would be welcome.

question: since there are many ways to implement this and to do so we would have to settle on one implementation and then that becomes canon for every user of the frame work. Should there be an RFC to discuss what implementation Ember should enforce?

thought: I don't wish to detract from this idea but whenever I was faced with serializing objects to search params I used encodeURIComponent(JSON.stringify(...)) Why not that as a default convention?

[sukima]

Should Ember be prescribing how to serialize an unknown object structure? Arrays are one thing but any ol' object seems a bit over reaching. If this were in my app I think I'd use a layer between the query params and the use of the data.

export default class MyController extends Controller {
  queryParams = ['filter'];
  @tracked filter = '';

  get filterObject() {
    return JSON.parse(this.filter);
  }

  setFilterFromObject(filterObject) {
    this.filter = JSON.stringify(filterObject);
  }
}