feat: ssr select value

[paoloricciuti]

Closes #7160

Bit of a disclaimer...don't know if we should actually do this but this implementation seems to work. It might be a breaking change if someone was relying on this quirky behaviour for some reason also i don't like the fact that it makes testing a bit harder (since a purely client side renderer component will not have the selected attribute) which is also why I had to update multiple tests.

Let's discuss if we want to merge this or not (also if you spot any glaring issues let me know).

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

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

[svelte-docs-bot]

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

[github-actions]

Playground

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

[Rich-Harris]

This makes total sense to me, I think it definitely qualifies as a bugfix

[paoloricciuti]

Btw didn't add a test for cross component select->option relation ship but it should work. Should we add one just to be safe?

[Rich-Harris]

also if you spot any glaring issues let me know

Couple of things:

• it doesn't handle implicit values — <option>foo</option> is equivalent to <option value="foo">foo</option>
• spreads are handled incorrectly (it only recognises the first spread attribute, disregarding any subsequent spreads or value or bind:value, and it evaluates the attribute a second time which could have consequences)

Should we add one just to be safe?

Yeah, can't hurt

[paoloricciuti]

it doesn't handle implicit values — foo is equivalent to foo

Uh weird I specifically tested this this morning and it was working...will look into that

[paoloricciuti]

Ok i think i fixed everything @Rich-Harris ...the problem with spread was also there for option.

I think there's one other problem which I'm not sure how to fix: what happens if the content of a value-less option is not statically analysable? (i think the only case is if you have a snippet rendered inside but it's cases nonetheless)

[paoloricciuti]

Yeah this is broken right now, let me add a failing test while i try to think of something

[paoloricciuti]

I guess we can try to do it it at runtime tho...let me try

[paoloricciuti]

Ok i think I fixed it...basically if there's a valueless option we do something like this

import * as $ from 'svelte/internal/server';

export default function App($$payload) {
	$$payload.out += `<select>`;
	$$payload.select_value = true;
	$$payload.out += `<option>`;

	const $$body = $.valueless_option($$payload);

	$$body(() => {
		child($$payload);
		$$payload.out += `<!---->`;
	});

	$$payload.out += `</option>`;
	$$payload.select_value = void 0;
	$$payload.out += `</select>`;
}

and the $$body function store the current payload, runs the children, remove the old payload from the payload after child, clean that from eventual comments, and compare the two.

I fully expect 10/15 simplify commit but it should work 😄