feat: $props.id(), a SSR-safe ID generation

[adiguba]

A work and progress implementation for #7517 (SSR-safe ID generation)

It introduce a new constant $$uid, unique for each instance of a component, based on this comment from dummdidumm (edit: sorry for the tag on sunday : it was not intentional) : #7517 (comment)

The id will be generated by a simple counter, prefixed by s on server side, and c on client side in order to avoid conflict.
On server side, a comment like <!--#s100--> will be generated in order to "pass" the ID for hydrating the client.

<div id="{$$uid}-title">The title</div>

<label for="{$$uid}-firstname">First Name: </label>
<input type="text" id="{$$uid}-firstname" />

<label for="{$$uid}-lastname">Last Name: </label>
<input type="text" id="{$$uid}-lastname" />

<div>My UID is {$$uid}</div>

Note :

• I'm not sure if this syntax is acceptable, or if a runes $uid() would be more appropriate.
• I haven't done any testing yet, but I could take care of it if the proposal is accepted.
• Currently $$uid can be used in a svelte.js/ts file, but this causes an error at runtime. I don't known how to handle this...

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: adbcbd7

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

[github-actions]

Playground

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

[Ocean-OS]

I like this, but I'm not sure if it should just be a function imported from the svelte module. The $$stuff syntax reminds me of a relic from Svelte 3 and 4. But then again, this does feel more integrated with your component than something like this...

<script>
import {createUID} from 'svelte';
let uid = createUID();
</script>

However, I also don't think it should be a rune, as not everything should be a rune; in my opinion, if it can be easily recreated while still writing less code, it doesn't need to be a rune.

[dummdidumm]

This should be either a rune or regular function - not sure which one makes more sense. I lean towards function.

[adiguba]

A regular function may not be possible, as it need to generate an hydration comment.

So do I adapt it into a rune ?
Something like :

$uid(); // return "s100"
$uid('title'); // return "s100-title"

[Ocean-OS]

A regular function may not be possible, as it need to generate an hydration comment.

So do I adapt it into a rune ? Something like :

$uid(); // return "s100"
$uid('title'); // return "s100-title"

I'm not sure if it should be an independent rune, or if a rune called like $server or sth should be added to group any new features that get added that relate to this sort of feature, with this feature being put under $server.uid, for example.
However, I would still want to try to keep this as a regular function if possible.

[Rich-Harris]

What about $props.id() or something? That way it's clear that it's a once-per-component thing, and that it doesn't work in .svelte.js files

[adiguba]

Yes an $props.id() seem a good solution to me :

<script>
    const uid = $props.id();
</script>

<label for="{uid}-firstname">First Name: </label>
<input type="text" id="{uid}-firstname" />

<label for="{uid}-lastname">Last Name: </label>
<input type="text" id="{uid}-lastname" />

I will try to implement it

[adiguba]

Demo here : REPL

The following code :

<script>
    const uid = $props.id();
</script>

Will be compiled to something like that in server-side :

const uid = $.props_id($$payload);

The function $.props_id() will generate an unique id, and write a comment like <!--#xxx--> for hydration.

On client-side, this code will be compiled as :

const uid = $.props_id();

The function $.props_id() will read the server's unique id on hydration mode, or generate a new value otherwise.

[webJose]

Why start in 100? Start with 1. Less characters, less bytes to transfer.

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-15185-svelte.vercel.app/

[Rich-Harris]

made some small tweaks and added some docs and I think this is ready to go. Thank you @adiguba! Great feature

[adiguba]

Nice !

[david-plugge]

It seems like this can only be used within the components code. Lets say i want to build a class within select.svelte.ts that implements the logic for a custom select component. Could i use$props.id() in that class IF it would be invoced on component initialization?

[adiguba]

No you cannot use it on *.svelte.js
props.id() add a hydration comment on the generated code, so it need to be present on the init script of the component.

But you can just pass it as param :

// select.svelte.js

export function init(uid) {
   ...
}

<script>
   import { init } from './select.svelte.js'

   const uid = $props.id();
   init(uid);
</script>

[adiguba]

I just added a small example code in the doc...

[bennymi]

- When hydrating a server-rendered a component
+ When hydrating a server-rendered component

[adiguba]

I pushed the change.
But I'm not sure if it's the correct way to accept the contribution

[bennymi]

All good, just noticed it. Thanks for updating it 👍

[bennymi]

Same here.

[Rich-Harris]

Just realised we never merged/released this, oops! Happening now. Thanks @adiguba

[Rican7]

Wow, fantastic job on this!

It's all well communicated and considered, with a nice useful scope, good docs, and it's also just a simple to understand feature. 👏🙌

[cschroeter]

@adiguba @Rich-Harris

Great feature! One minor downside for DX: it's no longer possible to assign $props() to a variable named props, as it now needs a different name:

  const props: AccordionRootProps = $props() // No longer possible  
  const id = $props.id()

  const rootProps: AccordionRootProps = $props() // Works  
  const id = $props.id()

[paoloricciuti]

@adiguba @Rich-Harris

Great feature! One minor downside for DX: it's no longer possible to assign $props() to a variable named props, as it now needs a different name:

  const props: AccordionRootProps = $props() // No longer possible  
  const id = $props.id()

  const rootProps: AccordionRootProps = $props() // Works  
  const id = $props.id()

This code works at runtime...the error should just be from the language server but that's already been fixed (we just need to release the new version)