Add params to goto() options

[yuliankarapetkov]

Describe the problem

When navigating to another page with query params, you have to provide them in the form of a string, which is not optimal in some cases.

For example:

const query = new URLSearchParams();

query.set('foo', bar);
query.set('anotherFoo', 'bar-as-string');
    
goto(`/some-page?${query.toString()}`);

or

const query = new URLSearchParams({
  foo: bar,
  anotherFoo: 'bar-as-string'
});
    
goto(`/some-page?${query.toString()}`);

Describe the proposed solution

We can get inspiration from Routify's approach and do this instead:

goto$('/some-page', {
  params: {
    foo: bar,
    anotherFoo: 'bar-as-string'
  }
});

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[Conduitry]

You can also just do new URLSearchParams({ foo: 'bar' }) which seems sufficient to me. You don't even need to call .toString() inside a template string because that will happen automatically.

Edit: I see now you suggested that constructor syntax in your second alternative. I don't feel there's a need for support in the framework for this to avoid a userland call to this constructor.

[yuliankarapetkov]

You can also just do new URLSearchParams({ foo: 'bar' }) which seems sufficient to me. You don't even need to call .toString() inside a template string because that will happen automatically.

Edit: I see now you suggested that constructor syntax in your second alternative. I don't feel there's a need for support in the framework for this to avoid a userland call to this constructor.

I agree it's almost the same but avoiding the constructor makes the code cleaner and easier to read - less parentheses, etc.

goto(`/my-page, ${new URLSearchParams({ foo: 'bar' })}`);

goto('/my-page', { params: { foo: 'bar' } }); 

IMO, it would have been even better/cleaner if the second parameter of goto() is in fact the search params and the options are the third one but that would introduce a breaking change which is probably not worth it:

goto('/my-page', { foo: 'bar' })

[Rich-Harris]

This feels very unnecessary to me — in any situation where you want to put the search parameters inline you can just include them in the string directly:

// this proposal
goto('/my-page', { params: { foo: bar } });

// inline string
goto(`/my-page?foo=${bar}`);

If we added a params option we'd have to figure out what takes precedence when params are specified via the first argument and the option, and we wouldn't be able to handle things like ?filter=x&filter=y (unless the object could have array values, which would be a terrible design decision). We'd be expanding the API surface area (which means more documentation to read, and more code/tests to maintain) and adding bytes to the client side bundle for very little benefit.