The Angle Bracket Invocation RFC was merged a few weeks ago and implementation work started shortly afterwards. After identifying the missing pieces needed and working through the checklist there, we have now enabled the feature by default on canary builds. Assuming all goes well during the canary cycle (e.g. we don’t find bugs that are intractable) the feature will land in Ember 3.4.0.
We’d love as much feedback on the feature as possible, but folks rarely test features that can’t be used in stable versions yet. So @mmun and I figured that a great way to get folks to “bang on it” would be to make it possible for addon authors to start using it without dropping support for their currently supported Ember versions. It turns out that we were able to do a fairly good approximation of the “headliner features”. Check out the polyfill here.
Please test (both the polyfill and the feature itself) and report back!
Hmm. I like this idea of addons being platforms for testing (being able to support new features but also making it backward compatible with their supported Ember versions). But I guess that’s not always viable and would be on a case-to-case basis.
Anyways, is it
It is whichever is the path to the curried / closure component . I think you are asking if there is a “capital letter requirement” when invoking dynamic components (either via a block param or via a service / local path), and the answer is: no.
There may need to be warning that on build systems with case-insensitive filesystems that there could be some ambiguity on how the Ember-CLI build system will resolve component names.
Right now, we are still storing components on disk in the dasherized form (which would be all lowercase still), so there should not be any change to the on-disk format (and therefore no new issues for case insensitive file systems).
There are some on the core team that definitely want to use capital case in the file system in addition to in the templates, and if we ever did that we would absolutely need to deal with those on-disk casing concerns…
I just released an update to the polyfill to bring it even more in line with the RFC. Specifically, the polyfill just landed the ability to specify
...attributes in its own template to “forward” its invocation attributes onto that element (or nested angle bracket invocation). As part of this update the polyfill is a bit more optimized around updates (only specific attributes that have changed will be updated now, instead of all attributes if any of the I invocation attributes had changed).
Nice work I was just asking about the status of this recently.
While working on some bugs that folks had reported, I also ended up creating a polyfill for the named arguments feature (which landed in Ember 3.1):
The polyfill can be used on the same set of Ember versions as the angle bracket invocation polyfill (2.12, 2.16, 2.18, 3.1+), and is yet another way for addons to begin using newer syntaxes (named args in this case) right away.