-
-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Svelte typescript: Props with default values cause Type error of missing props #276
Comments
A proposal of this has been discussed here #214 (comment) Might be a good way to improve how the props is determined to be optional |
We did originally not do this because it seemed very hard to track down if the initializer itself is initialized. Example: let a: string;
export let b = a; @jasonlyu123 Or is this no longer relevant / did you find a way to deal with this? |
Oh! That's an issue. No. I don't have any solution for this. |
Maybe we could at least relax and fix it for 90% of the cases like this: If initializer is not a variable, mark it as optional. |
Svelte dev build actually has required props checking. It only checks if the variable declaration has initialize expression. this is how it checks: |
Thought about this some more: I think we should mark props as optional as soon as any kind of initializer is given. Typescript itself will make sure that usages are correct, so this is safe to do. |
Sounds reasonable. |
Sounds good! One thing about your changes: you removed the |
That's true, like I explained in #214 (comment), this is the correct behavior in my opinion. But if you think we should still mark a variable as optional if it has the |
Mhm, that's true, it's more in line with how the svelte compiler treats it. Also it's a difference in strict mode if you type a prop as undefined or optional I think. You convinced me 😄 |
//component code
when component is added without providing the Prop "name", vs code shows this error
component = Service
Currently I'm getting rid of this by adding explicit types
we shouldn't have to do this right, can't we infer the type from the default value assignment?
or are there any other syntax (like '?') to make this more cleaner....
or am I doing something wrong?
The text was updated successfully, but these errors were encountered: