-
-
Notifications
You must be signed in to change notification settings - Fork 408
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
Loosen restrictions around component argument names #803
Comments
The current naming convention is also not fully enforced. You can set an argument starting with an underscore using |
Both cases make sense to me, esp. the capital-case component name ( |
This is also directly related to the fact that there is no syntactical restriction on component invocation in strict mode templates—basically by definition: if the name from the surrounding JS scope is available to invoke, then any legitimate JS identifier needs to be invokable. That means that |
@chriskrycho what would an RFC for this look like? Are you able to give any pointers to @bertdeblock ? |
Wellllll, actually we might want to go the other direction. @dfreeman discovered some non-trivial issues with allowing |
@bertdeblock happy to sync with you out-of-band (via Discord or whatever works for you) to work together on figuring out how this relates to the issues Chris mentioned above and whether it makes sense to join forces 🙂 |
At the moment, only argument names starting with a lowercase letter are allowed.
I think it would be nice if this restriction could be loosened for the following use cases:
The PascalCase argument name makes it clearer that we are passing along a component,
and is also inline with how the component is normally invoked (
<Bar />
).The underscore makes it clearer that this argument can only come from its parent,
and is not meant to be used publicly when invoking the child component.
Both cases also work in JS land:
this.args.Bar
this.args._foo
Mainly opening this issue to see if other people think this is a good idea,
and to see if other uses cases are missing.
Totally up for writing the RFC myself if this turns out to be a good idea.
The text was updated successfully, but these errors were encountered: