chore: rewrite set_class() to handle directives

[adiguba]

Currently the class:xxx directives are managed separately from the class attribute.

This is a PoC for rewriting set_class() in order to includes class: directives.

• Closes bug: The class: directive don't remove existing className on SSR #15338
  The SSR don't remove the class based on the falsy class:xxx directives.
• Closes Useless mutations with class: directive #15351
  The class attributes is set globally, based on attribute, hash and class: directives.

Note that I edited some tests, just for removing leading whitespace.
Basically :

-<p class=" svelte-xyz">Foo</p>
+<p class="svelte-xyz">Foo</p>

[edit] I think that the same thing may be applied to style and style:directive

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

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

This PR includes changesets to release 1 package

Name	Type
svelte	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

[github-actions]

Playground

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

[adiguba]

Example (client side) :

<div class={className} class:bar class:baz>...</div>

Currently it's compiled into something like this :

	$.template_effect(() => {
		$.set_class(div, $.clsx($$props.className));
		$.toggle_class(div, 'bar', $$props.bar);
		$.toggle_class(div, 'baz', $$props.baz);
	});

	let classes;

	$.template_effect(() => {
		classes = $.set_class(div, 1, $.clsx($$props.className), null, classes,
			{ bar: $$props.bar, baz: $$props.baz}
		);
	});

The version of set_class() will set the full className on hydration or when the base value is modified.
Otherwise it will handle the class:directive one by one, based on previous value.

[adiguba]

On server side :
Currently :

$$payload.out += `<div${$.attr('class', `${$.stringify($.clsx(className))} ${$.stringify([bar ? 'bar' : '', baz ? 'baz' : ''].filter(Boolean).join(' '))}`)}>...</div>`;

With this PR :

$$payload.out += `<div${$.attr('class', $.to_class($.clsx(className), null, { 'bar': bar, 'baz': baz }))}>...</div>`;

$.to_class() is a shared function, used internally by set_class() on client-side to generate the class value.

[Rich-Harris]

thank you, this is looking good! left a few small notes

[adiguba]

Initially, I added the style_directives because I thought I would do set_style() the same way at the same time...
But I will do it in a separate PR if this one is accepted...

[Rich-Harris]

thank you!

[adiguba]

Nice !

I will prepare a similar PR for style and style: !

But, sorry for my ignorance: why did let/const are replaced by var ?
I always thought that the latter was no longer really recommended...

[Rich-Harris]

We tend to use var in runtime code because it's faster — engines don't need to do TDZ violation checks. Sometimes it's necessary to use let/const for scoping reasons or because TypeScript gets confused with var, but other than those cases we default to var