Unexpected angle-bracket component invocation.

[lifeart]

Given:

• component, named foo-bar.
• component/controller context.

component-or-controller

this.someName = 'foo-bar'

context-related template

<this.someName />

result

foo-bar component rendered, instead of error or <foo-bar /> tag rendering.

Reproduction:

https://ember-twiddle.com/#/4d2f5e2d56d204de0a74090e6d728b84?openFiles=templates.application.hbs%2C

May be related to:
1aa4fbb#diff-e6d62c9fc48e7201f4f2e4b9a3d52fa7

[rwjblue]

Ya, this should assert

/cc @chancancode

[chancancode]

@rwjblue I know how to add the assert via the same ast transform (basically turning it into {{#let (assertion this.someName) as |__secret__|}}<__secret__ />{{/let}}). But how do we feel about adding more of that assertion right now given we don't have a dev vs prod mode distinction?

[ef4]

I don't understand why this would be implemented as an assertion before invocation rather than making sure invocation never supports strings?

I would have thought that invoking a string is an opt-in behavior that requires wrapping in {{component}} and that's the only place where dynamic string values should be getting resolved into components?

[chancancode]

Mostly just a hack before implementing it in glimmer can and updating to use the latest glimmer vm here. This assertion already exists for curlies etc. Part of the reason is a lot of the dynamic invocations are themselves hacked on top in ember via ast transforms without proper vm support. The reason the curly/dot rule version fails is because we literally transform them into component helpers, which do support strings.

[rwjblue]

FYI - I submitted a failing test for this over in glimmerjs/glimmer-vm#1149. Did some digging with @krisselden and @pzuraq to determine what is the real cause (usage of builder.dynamicComponent, which is also the same thing that supports {{component helper so it includes resolution). I believe that @pzuraq has a fix, that we'll hopefully be able to land for Ember 3.23.0-beta.1...

[robclancy]

I don't see how this was an issue? I was using this and thought it was a nice feature. Was nice not having to hack around the broken attributes with the component helper (I couldn't just swap in the helper, I have to use let so I can have attributes).

[ef4]

It’s a big deal because of the way it defeats static analysis. An app that does this anywhere can’t shake out unused components everywhere.

For some alternative ways to get the component invocation you want, see https://github.com/embroider-build/embroider/blob/master/REPLACING-COMPONENT-HELPER.md. Depends on your use case, but the patterns suggested there might help.

[robclancy]

Well looks like this has done more than stop strings. I get an infinite loop until I run out of memory now if I use a component passed in a hash that is made using the helper.
<Comp @comps={{hash comp=(component 'something')}} />
<@comps.comp /> <- infinite loop crash tab fun

[ef4]

I just tried to reproduce that and couldn't. If you can make it happen reliably please file an issue with the reproduction and I'll take a look.

[robclancy]

It was due to something changing with helpers and a Object.assign was modifying the original params sent into the helpers whereas before it wouldn't. So a component was calling itself over and over recursively since it replaced the parent version with itself.