feat: add svelte/reactivity/window module

[Rich-Harris]

These are preferable to the existing <svelte:window> bindings insofar as they can be used in more places, and with less boilerplate. Before:

<script>
  let width = $state();
  let height = $state();
</script>

<svelte:window
  bind:innerWidth={width}
  bind:innerHeight={height}
/>

<p>{width}x{height}</p>

After:

<script>
  import { innerWidth, innerHeight } from 'svelte/reactivity/window';
</script>

<p>{innerWidth.current}x{innerHeight.current}</p>

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
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

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

[changeset-bot]

🦋 Changeset detected

Latest commit: 40c33e9

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

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

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

[Rich-Harris]

preview: https://svelte-dev-git-preview-svelte-14660-svelte.vercel.app/

this is an automated message

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@14660

[trueadm]

What about window.location? Should we support reactive versions of those too?

I also wonder about events, specifically not needing to have them for things like window.online if we can provide a reactive boolean version. However, maybe having an event handler version is best:

<script>
  import { onWindow } from 'svelte/reactivity/window';

  onWindow('online', () => {

  })
</script>

Then it reduces to need to use <svelte:window> entirely.

[dummdidumm]

Hid some internal types and added online so that all current bindings have an equivalent in svelte/reactivity/window. For full parity we would need to make scrollX/Y.current writable.

[Rich-Harris]

What about window.location?

There's no event that fires when it changes, so we'd need to monkey-patch history.pushState and history.replaceState which feels kinda gross. We also wouldn't want people using these over page.url in SvelteKit apps (since that creates a timing problem).

I like the idea of event listeners in theory but I'm not sure what a good API looks like, so I don't think we should add it to this PR.

For full parity we would need to make scrollX/Y.current writable.

Yeah, I thought about that, but to be honest I'm not sure it's a good idea. The scenarios in which you should be programmatically manipulating scroll are very few and far between, and scrollTo({ top }) is less code than scrollY.current = top and lets you pass a second options argument with behavior. We should just encourage people to do that instead.

[dummdidumm]

Yeah fine with me - especially now that you can pass functions to bindings, so you're not forcibly reduced to member expressions anymore in that situation (man, this feature is really paying dividends)

[trueadm]

For window.location we could listen to popstate event?

[Rich-Harris]

popstate doesn't fire when you push or replace state