There you are in a template. It’s dark outside, the weather is rough, and you encounter the double curlies. Not familiar with the app, since it was just given to you by your boss a few hours ago, you start to pull your hair. Is it a helper? A property on the component? Is it an attribute passed in? After digging around frantically (probably using ctrl F, or command F for the mac people) you discover it’s a property of the component. Why the ambiguous nature of the curlies? For ages, every Ember developer has been putting this uncertainty into the hands of the default property
fallback. Whatever shall we do?!?
The new RFC for deprecating the property fallback behaviour
in Ember aims disambiguate the curlies and remove the confusion when reading a template. To provide clarity, the PR proposes ((this.foo))
, being foo
a property. By doing this, it is certain that the property belongs to the component class. While not the main focus of the proposal, the PR could have positive effects on the rendering system by reducing compiler overhead
when discovering the true intent of the curlies in question. Even though this is still in discussion, it certainly provides a path forward that to enrich
the developer experience
. Make sure to read the discussion – which includes a post by @wycats
on how various recent RFCs tie in together into a coherent future for the framework future
– and make your opinion heard in the comments section.
recently posted the “Glimmer Components in Ember
” quest issue to lay out the work necessary to bring Glimmer components to Ember
. This gives developers an option to use all the nice things Glimmer components have to offer while living alongside the current Ember.Component
The quest is split up into a number of Phases:
This is an exciting time to be an Ember developer! And with EmberConf around the corner, things can only get better!