Feature: Ability to restrict types accepted by component props

[Ocean-OS]

Describe the problem

Sometimes when making components, you want to have a component that only accepts props with specific types. However, Svelte doesn't directly assist with this, (unless you use TypeScript), so you have to figure out how to handle invalid props.

Describe the proposed solution

Add a rune for props that only accept certain types. These types would be both primitive types (string, number, object, etc), and classes. The rune would be used in a similar syntax as $bindable(), in the default values of the $props() declaration. If an invalid prop is used, Svelte could throw with an error code similar to invalid_prop_type. I have a few ideas for what this rune would be named and how the rune's syntax would work:

Possible names

• $props.accepts()
• $props.restrict()
• $props.type()
• $props.only()

Or it could be a standalone rune, which would mean cleaner code, but I don't know if it's important enough (not to mention it could look more confusing to new Svelte users):

• $only()
• $accepts()
• $type()

Possible arguments syntax

• An object with the primitive types accepted in a type/typeof property, and the class types in an instance/instanceof property (example: $props.only({typeof: ["string","number"], instanceof: Class}))
• An array or multiple arguments with the constructors of the classes accepted and the primitive type names accepted (example: $props.accepts("string", "number", Class)

Full syntax example

<script>
let {onlyStringOrNumber = $props.type("string","number"), onlyClassInstance = $props.type(Class)} = $props();
</script>

Minor details

• I'm not sure how a bindable prop that only accepts certain types would work. It might just be like wrapping the accepted types in a $bindable (example: prop = $bindable($props.accepts({typeof: "string"}))) or something else entirely
• I'm not sure if there should be a way to control whether an invalid prop throws or warns. Throwing should be the default, but I don't know if there'd be a reason to have the ability to warn instead.
• I'm not sure if this should also restrict whether the value can be reactive or not (eg: <Component prop={1}> is not reactive, but <Component prop={thing}> is reactive). If so, I'm also not sure if this would be a separate rune ($props.static/$props.reactive?) or just another part of the type restriction rune.

Importance

would make my life easier

[dummdidumm]

To be clear do you need/want this to be a runtime feature? Because if you're not using typescript you can also use jsdoc to type the props.

[Ocean-OS]

To be clear do you need/want this to be a runtime feature? Because if you're not using typescript you can also use jsdoc to type the props.

I mean, I could still just use something like this:

if(typeof prop !== "string" && typeof prop !== "number" && !(prop instanceof Class)) {
throw new Error("prop can only be a string, number or Class instance") 
} 

But when multiple props should only be certain types/instances this becomes a very tedious and repetitive script.
Additionally, as of right now there isn't a way to tell if a prop is static or reactive in Svelte unless you use eval or some other unsupported workaround. Having the ability to tell/enforce if a prop is reactive or not would be useful for things like DOM operations or object methods. If a prop is reactive, and its value changes, you would have to put the code that works with the prop in an $effect. However, sometimes you don't want a prop to be reactive because your use case can't deal with reactive props, but you can't enforce this.

[webJose]

If I'm understanding correctly, you want a built-in runtime type-checking feature that will work just for properties. As I understand this, you don't use TypeScript, and apparently you also don't use JsDoc.

My very own personal opinion is not to add this kind of thing. Why? Performance. I'd much rather pay the transpilation price of TypeScript and have a faster runtime. Furthermore, this should be largely unneeded. My reasoning behind this is: If I create component A for my own consumption or my team's consumption, I (or we) won't be sabotaging ourselves purposely sending wrong data types. Furthermore, we do use TypeScript so the error would be obvious.

I guess the key question here is: What needs validation? My personal answer is: User-provided data, because guarding against developers is far less a need (maybe just component libraries should care a little bit about it). So where should we validate things? At the form level of an application. Is this directly related to properties of a component? I'd say No.

This kind of thing is too focused to one thing: Properties. I bet that if the feature existed, its algorithms would probably work for other places, so why restrict it. But if it work elsewhere, why should it need to be a Svelte feature? If it doesn't need to be a Svelte feature, it can probably be a general-purpose NPM package. I bet there are several out there already. I think zod is the name of one? Usually used in tandem with database-driven apps.

[AlexRMU]

see also #13124

[webJose]

Yes, this sounds a lot to what packages like zod does. Just use those, I'd say, unless there are use cases where this is not a good thing to do?