fix: reinstantiate state parameter for goto

[dummdidumm]

This reinstantiates the state parameter for the options argument to goto. In the original shallow routing PR, this was mentioned as the alternative, and it may make sense to do it this way instead of requiring people to do await goto(..); replaceState({ ..}) instead of just goto(..., { state: { .. } }). It also means the page store is updated directly, and doesn't have a tick were it's empty.

Open for debate if we really want to do this, but the change itself is rather easy so I thought I'd open the PR. Probably needs a test if we reinstantiate.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4728a54

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benmccann]

This seems preferable to me than having the user make two calls. This is more atomic than having it in an undesirable state in between the two calls

Are there 1.x deprecation warnings that need to be removed as well or anything in the migration tool?

[Rich-Harris]

I'm not sure about this — it's pretty weird to keep an API but change its behaviour. If you do this...

await goto(...);
replaceState('', state);

...then there's no undesirable in-between state

[dummdidumm]

There will be a tick in which the page state is empty and it's updated to being a state afterwards. It's different from being set immediately.
Also the API doesn't change, this isn't even a breaking change if you would do that in 1.x because $page.state wasn't a thing previously, and the only difference is that the object the user passes in is no longer manipulated to also include the history etc index.

[WaltzingPenguin]

Another argument for this: Preserving state across a navigation. This is a lot more awkward than it was prior to 2.x

const state = $page.state
await goto(e.currentTarget.href, {
  replaceState: true,
  noScroll: true,
  keepFocus: true,
})
replaceState('', state)

vs

await goto(e.currentTarget.href, {
  replaceState: true,
  noScroll:true,
  keepFocus: true,
  state: history.state
})

If context helps, the page has three different tabs. Each tab has its own url and load function. The tabs are styled using material design so creating navigation history would be surprising. history.state contains information about how the user got to this page, so I know what animation (cover/reveal/etc) needs to played when navigating away.