Introduce <AngleBracketInvocationSyntax />

[chancancode]

Rendered

[sclaxton]

I’m pretty opposed to overriding the proposed syntax for passing named blocks structurally, i.e. <@foo></@foo>. In my mind this syntax is pretty important for representing the mental model that named blocks are really just the same as passing the block as an argument. It also seems more natural syntactically that thing inside naked angle brackets should treated as static names rather than dynamic expressions. Could we not instead have dynamic invokation be expressed with curlies? <{{@foo}}></{{@foo}}> seems to convey dynamic-ness to me more than <@foo></@foo>.

[mmun]

In my mind this syntax is pretty important for representing the mental model that named blocks are really just the same as passing the block as an argument.

I strongly agree with this and it's one of the reasons why I prefer the <@foo=>...</@foo> block-passing syntax (with the equal sign) over bare <@foo>...</@foo>. My hunch is that the latter syntax will lead people to assume this syntax behaves like HTML children rather than as arguments for the component.

The second reason is that the <@foo>...</@foo> block-passing syntax prevents us from having a <form.submit>...</form.submit> syntax for invoking contextual components. This feature is very important to me. When I've worked with JSX in the past I've really enjoyed the simplicity of being able to do this.

[sclaxton]

@mmun those are fair points. It still feels weird to me to allow dynamic expressions outside of curlies, e.g. <this.someProperty />. With the exception of maybe the ...attributes keyword in glimmer, it seems like we’ve kept dynamic expressions within curlie braces. This seems like a pretty big departure from that. Can someone speak to the rationale behind that decision? @chancancode @wycats

P.s. Thinking out loud: requiring curly-braces for dynamic invocation would also solve the block local variable issue:

<MyForm as |foo|>
  <{{foo}} />
</MyForm>

[tchak]

Is it really not possible to support positional params?

[joukevandermaas]

I'm assuming 'classic component' is a reference to the component manager RFC? Initially this paragraph was (maybe still is) very confusing to me. I guess I can understand the point of the question if I assume the following:

1. 'Classic components' (current-day Ember components) do not support ...attributes, so throwing an error when they are not used seems wrong (at least initially)
2. Glimmer components do support it so they will work as described in the paragraphs above

Can someone please correct my understanding if it's wrong?

[mmun]

Yes, that seems correct.

I think that classic components should fully support ...attributes and that we should automatically insert ...attributes to the wrapping element if it doesn't appear in the template and tagName: '' hasn't been used.

This would allow people to immediately start using HTML attributes with their classic components and remove the need for hacky add-ons like https://github.com/mmun/ember-component-attributes.

[joukevandermaas]

I really don't get this. They are not semantically equivalent. An immediately closed tag has a block, but it's empty. Is there some technical reason why they should be the same?

[mmun]

I agree. <Foo></Foo> should have a block with no content whereas <Foo /> should not have a block passed at all (similar to {{some-component}}).

[mmun]

The RFC was alluding to some of the technicalities around self-closing tags in the HTML spec, but I think it's ok to make small refinement to the semantics for angle bracket component invocations.

[mmun]

@tchak My gut feeling is that positional arguments don't really fit well the angle bracket component invocation syntax and should remain a curly component thing (which aren't deprecated!), but I'd be interested to hear compelling use cases or syntax ideas. Keep in mind that any syntax ideas should be compatible with #112.

[averydev]

I'm curious whether the long term goal is for there to only be the angle bracket syntax, or whether there would always be curlies and angle bracket options?

[Gaurav0]

As a practical matter, I would like to be able to convert to angle bracket syntax, especially for the one way binding advantages. However, my large work app has lots of nested components and not being able to traditionally nest components in directories pretty much means we will have most of our components remain curly components indefinitely. I think this is pretty much true of any large enterprise app.

I think a way to invoke components nested in directories globally is absolutely necessary if large enterprise apps are ever going to be able to migrate. While it is possible to hack the resolver, I would prefer a shared solution.

Note: The current RFC draft does not explicitly forbid slashes. This should be added if they are not going to be supported as previously expected.

[sclaxton]

What types are permissible for this.foo in this case? Curried component? String?

[courajs]

@chancancode this proposal doesn't include the one-way binding semantics @Gaurav0 mentions, correct? That was part of the original angle brackets proposal, but has been removed here?

[courajs]

I'm slightly concerned about how the capitalization interacts with native HTML elements. Right now, <Button>Press</Button> will render the native browser button tag. Does this need to come with the specification that native elements must always be specified lower-case in templates?

[courajs]

I think {{has-block}} should probably return false for self-closing tags, and true for immediately-closed tags. Then, these would correspond more closely with curly invocation - self-closing is the inline invocation form, and immediately closed is the block form.

Since a lot of components use has-block to render default content, there should be a way to send no block. If it returned true for self-closing tags, we'd need to specify some other way to pass no block. Currently you'd have to do something like <Comp @main={{null}} />, but adding some other additional syntax seems likely to feel awkward as well.

[Panman82]

I think {{has-block}} should probably return false for self-closing tags, and true for immediately-closed tags.

Agreed, it seems more semantically correct. IMO, if it returns false for immediately-closed tags then it would be more appropriately named {{has-content}}. Perhaps add both for additional information.?.

I'm curious whether the long term goal is for there to only be the angle bracket syntax, or whether there would always be curlies and angle bracket options?

I'd like to add, years back when I first looked into front-end frameworks I wanted angle-bracket components. But now I'm not so sure, curlies seem to be a better fit. Take it as a grain of salt, just my own feelings ATM.

[chancancode]

I have updated the RFC to reflect a few things we discussed in the EmberConf core team meeting:

• For now, <Foo /> (where Foo is a local variable) will be the only kind of dynamic invocation allowed. This makes all component invocations uniformly start with a capital letter and allow for more time to collect feedback on what other forms of dynamic invocations should be allowed.

• Classic components will have ...attributes added to the wrapper element.

• <Foo /> will have {{has-block}} set to false.

[chancancode]

I'm slightly concerned about how the capitalization interacts with native HTML elements. Right now, Press will render the native browser button tag. Does this need to come with the specification that native elements must always be specified lower-case in templates?

@courajs That is technically true, but I think it is very rare and almost never happens in practice. If we want to be super careful, we can put in a warning/error now to clear the space before rolling it out. Are you asking because you have seen this in the wild?

[chancancode]

I'm curious whether the long term goal is for there to only be the angle bracket syntax, or whether there would always be curlies and angle bracket options?

@averydev As stated in the RFC, curly invocation is here to stay. I think in the long term, curlies will be primarily used for things that are like control-flow (e.g. animated-each).

[chancancode]

this proposal doesn't include the one-way binding semantics @Gaurav0 mentions, correct? That was part of the original angle brackets proposal, but has been removed here?

@Gaurav0 @courajs This proposal does not include the one-way binding semantics from the original proposal. This proposal is really just just an alternative syntax for the existing invocation style (with some feature differences – one has positional arguments, the other has attributes).

The two-way binding semantics generally "doesn't matter" as long as you don't use it in the component classes. In the cases where they matter, they affect curly invocations just as much. Since we are proposing that they are both here to stay and there are good use cases for both, it is not really feasible to fix one but not the other.

I think we have better tools to fix that now (optional features, deprecations, etc), so I am pretty optimistic that we can find a way to fix that broadly. But if we somehow cannot do that, the divergence in semantics between the two invocation styles will be more of a problem in the long term.

[rwjblue]

the divergence in semantics between the two invocation styles will be more of a problem in the long term

I strongly agree. The current proposal supports gradual migration and straight-forward interop over broad sweeping changes. This will ultimately translate into fewer "cliffs" for existing applications...

[wycats]

@rwjblue @chancancode I agree with this. Since we don't think we're going to remove "curly invocation", and plan to keep it around for control-flow style abstractions (liquid-if), we're going to have to deprecate auto-mut for those cases anyway.

Additionally, Glimmer component classes do not see two-way bindings, since the Glimmer component manager doesn't create two-way properties on the component class, and also sets an immutable args object. The fact that angle-bracket components still nominally create two-way bindings is more-or-less a consequence of the fact that angle bracket components can be used to invoke classic component classes in this proposal.

(Aside: given this, we will need to decide how <Input> should be written using Glimmer component classes. We don't want to reify mut onto args today because of auto-mut, but maybe we would be willing to reify it after other changes?)

[Gaurav0]

Please specify if <A/b /> or <A/b>...</A/b> will be allowed to invoke nested components.

[rwjblue]

Please specify if <A/b /> or <A/b>...</A/b> will be allowed to invoke nested components.

This is not supported, I agree the RFC should be a tad more explicit in the Tag Name section.

[rwjblue]

@Gaurav0:

As a practical matter, I would like to be able to convert to angle bracket syntax, especially for the one way binding advantages.

There is no behavior change associated with angle bracket invocation. The support of two way bindings is entirely based on the base class of your component. This RFC does not propose to change that at all.

However, my large work app has lots of nested components and not being able to traditionally nest components in directories pretty much means we will have most of our components remain curly components indefinitely. I think this is pretty much true of any large enterprise app.

I agree that this complicates migration. It seems absolutely fine to continue using curly invocation (with nested directory structures) indefinitely! There is no proposal to deprecate or make curly component invocation "second class".

Please note though, that there are a number of ways that you can obtain grouping behaviors already (and even more on the way!). For example, you could use a file-name prefix along with in repo addons as a mechanism to namespace components (both physically and in the template).

If you look ahead a bit, you can see there are even more tools to aid in this. The new file system layout (being actively pushed forward by the community) provides both lighter weight namespaces and a very clear way to invoke them from the template. In addition to light weight namespaces, we are also adding local lookup capabilities. When leveraging local lookup you can easily scope components to a specific subdirectory so that they are only available within specific routes or components. The combination of these two things provide an even better mechanism for grouping that folders do!

I think a way to invoke components nested in directories globally is absolutely necessary if large enterprise apps are ever going to be able to migrate.

I agree to disagree with you. 😺 I believe the new file system layout with both namespaced packages and local lookup are wonderful paths forward to avoid that nested directory invocation.

While it is possible to hack the resolver, I would prefer a shared solution.

I agree that modifying the resolver is not a good long term strategy.

Note: The current RFC draft does not explicitly forbid slashes.

Yep, absolutely should be updated to make it much clearer.

This should be added if they are not going to be supported as previously expected.

This statement is pretty confusing. I am not aware of any prior proposal that allowed nested directory invocation.

[lmcardle]

What’s the plan to support contextual components. I agree with @mmun, this is an important feature with components today.

[mmun]

I still want a follow-up RFC for <f.input> but it needs works and its not necessary for merging the simple angle bracket invocation style. In the mean time {{f.input}} will continue to work...

[lmcardle]

@mmun, you can do this in jsx? I’m curious how they accomplish this, do you have a reference by any chance?

[mmun]

@lmcardle It wouldn't be using JSX, just inspired and validated by it. It would be implemented by changing the Glimmer parser.

[mmun]

typo: laid

[alexlafroscia]

Should be improvement

[Gaurav0]

Disagree that this feature is unnecessary. 📁 are the most natural way to organize components and are widely used in large applications. None of the alternatives presented in module unification are intuitive or easily transitioned to.

Recommend "Since this feature will not be permitted with...

[rwjblue]

After discussion with the core team this afternoon, we are 👍 on moving this RFC into the final comment period.

[oligriffiths]

Can I ask why <Foo @bar=123 /> is not supported, that the value must be {{123}}?

[yarigpopov]

<FooBar @foo={{123}} @bar={{this.bar}} />

I can imagine myriad of @ in my components) can I get <FooBar {{foo=123 bar=this.bar}} /> please?

Moreover, I see no point of having this @ just write <FooBar aria-role="some" {{foo=123}}/> how we do now for static HTML elements and use @ for something else).

[mikkopaderes]

@chancancode I didn't see anything that mentions {{yield to="inverse"}}. I'm guessing syntax would be the same?

e.g.

<Grid as |item|>
  <GridItem @item={{item}}>
{{else}}
  No item available
</Grid>

[rwjblue]

@rmmmp:

I didn't see anything that mentions {{yield to="inverse"}}. I'm guessing syntax would be the same?

Quoting from the RFC:

There is no dedicated syntax for passing an "else" block directly. If needed, that can be passed using the named blocks syntax.

[chadhietala]

Since 14 days have passed with no additional unaddressed comments, I'm going to merge this RFC.

[bravo-kernel]

Should the label not be removed?