Skip to content
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

Closed
Tracked by #816
bertdeblock opened this issue Mar 3, 2022 · 6 comments
Closed
Tracked by #816

Loosen restrictions around component argument names #803

bertdeblock opened this issue Mar 3, 2022 · 6 comments

Comments

@bertdeblock
Copy link
Member

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:

  1. Argument names starting with an uppercase letter (passing along a component via an argument to another component):
<Foo @Bar={{component "bar"}} />
{{! foo.hbs }}
<@Bar />

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 />).

  1. Argument names starting with an underscore (passing along a "private" argument from a parent component to a child component):
{{! parent.hbs }}
{{yield (hash Child=(component "child" _foo="bar"))}}
{{! child.hbs }}
{{@_foo}}

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.

@jelhan
Copy link
Contributor

jelhan commented Mar 19, 2022

The current naming convention is also not fully enforced. You can set an argument starting with an underscore using {{component _foo="bar"}} helper. You can not access it using the {{@_foo}}. But you can access it using {{this.args._foo}}`. 🤯 Using this in production at Ember Bootstrap. 🙈

@mydea
Copy link
Contributor

mydea commented Mar 21, 2022

Both cases make sense to me, esp. the capital-case component name (@Wrapper={{component 'my-component'}}) is something I've personally ran into multiple times.

@chriskrycho
Copy link
Contributor

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 <foo /> can be a legal component invocation, and passing @Foo={{bar}} should also.

@wagenet
Copy link
Member

wagenet commented Jul 23, 2022

@chriskrycho what would an RFC for this look like? Are you able to give any pointers to @bertdeblock ?

@chriskrycho
Copy link
Contributor

Wellllll, actually we might want to go the other direction. @dfreeman discovered some non-trivial issues with allowing div and friends as legal names in the context of what Glint needs to do, and notably Svelte and Vue have restrictions on names for the same reasons. I think Dan was planning to write up a related RFC; I suspect he would also be up for supporting/helping Bert doing the same.

@dfreeman
Copy link
Contributor

@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 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants