Argument Validation Primitives #694
Conversation
| lazy, and so we cannot know the values until they are used. | ||
|
|
||
| While `validateArgs` will be autotracked on its own, it will not be _consumed_ | ||
| by the external tracking contexts. This prevents it from impacting the tracking |
There was a problem hiding this comment.
it will not be consumed by the external tracking contexts
How is this guaranteed?
There was a problem hiding this comment.
We have the ability to disable autotracking contexts internally, and use it for various reasons (such as backwards compatibility). We have not exposed this capability, and generally don't think we will do so as in most cases it doesn't make sense, but I think here since this is a DEBUG only feature it may make sense. It does mean that validations may not rerun when you think they would, but it also prevents behavior from diverging too much in production.
| This method is only run in development builds, and is inert in production | ||
| builds. | ||
|
|
||
| ### `setValidateArgs` documentation |
There was a problem hiding this comment.
I really like this. Similar to composing validations on changesets.
|
Is there still interest in moving this forward? |
kategengler
added
the
FCP to close
|
We're putting this into FCP to close -- the way we write components has evolved a lot since this was proposed. |
|
Example of using a default value in gjs: function defaultFoo(x) {
return x ?? 'default value';
}
<template>
{{defaultFoo @foo}}
</template>and with typescript: function defaultFoo(x: string | undefined) {
return x ?? 'default value';
}
<template>
{{defaultFoo @foo}}
</template> satisfies TOC<{
Args: {
foo?: string;
}
}> |
Big thanks to @snewcomer and @rwjblue for helping with the initial design!
Rendered