Svelte: <input type='number' /> value isn't parsed as a number when `type='number'` attribute is spread instead of being explicitly written

[aarongeorge]

Describe the bug
An input like <input type='number' /> will parse the value as a number, however if you were to spread the type='number' onto the input it will be parsed as a string instead

Logs
N/A

To Reproduce
https://svelte.dev/repl/1d4158ad6d4f4203a7fe2bfbfa4c05ec?version=3.23.2

Expected behavior
Regardless of spreading the type='number' attribute or explicitly defining it, both should result in the value being parsed as a number.

Stacktraces
N/A

Information about your Svelte project:
REPL link uses v3.23.2

Severity
There is a work around, and that's to explicitly put the type='number' attribute. It's just annoying that I can't use the spread and results in a lot of duplication.

Additional context
N/A

[Conduitry]

This is the expected behavior. Svelte has to be able to see the type='number' at compile time to generate the code to convert the string to an integer as part of the two-way binding. We don't want to be including every type of handling on every <input> with a spread on it.

[skippednote]

I was looking into this and thank you @Conduitry for the clarification.

@aarongeorge Whenever the bound value changes it calls get_spread_update and it returns an empty object. Because of this the attribute type=number is removed from the input and the value is converted to a string instead of a number.

@Conduitry Does the spread object have to be marked as dirty in such a case?

[aarongeorge]

@Conduitry are you saying that by making this work as described in my original post that the resulting bundle size will be increased and there is more computation happening on the clientside, or that the compiler would be doing more work? It sounds like the former, but if it was the latter I'd rather the compiler take longer if needed to reduce the duplication on the code side of things.

@skippednote thanks for the links 👍

[Conduitry]

The bundle size would be increased. If the compiler can't tell at compile time what the type of an <input> is (which it can't when type is set by a spread) then it would need to include the relevant handling for type=text, type=number, type=radio, type=checkbox, etc.

[aarongeorge]

Thanks for clearing that up @Conduitry. Is computing what the type is at compile time technically infeasible or is it just something that isn't on the road map?

I'm just trying to understand if this is something that you'd like to have somebody contribute or if it's just something that isn't possible.

Thanks for answering these questions.

[Rich-Harris]

It's technically impossible. It's not just spread attributes, it's any type attribute that could potentially change at runtime, as seen here:

The only potential solution (which isn't something that's currently on the roadmap, though the roadmap is always subject to change!) is to allow people to opt in to chunkier bundles in cases where type is dynamic. Not sure exactly what that would look like in terms of syntax etc; either way that should probably be a new issue, if someone were to raise it.

[aarongeorge]

Cheers for the info @Rich-Harris 👍🏻