Ready for Release
The Ready for Release stage is a phase where the implementation is complete and we're preparing it for an official release. See the list of RFCs ready for release below.
#1000
Make array built-in in strict-mode
Make (array) a built in helper Summary Today, when using gjs/gts/<template>, in order make arrays in templates, folks must import the (array) helper. Because creating arrays is fairly commonplace, this is an annoyance for developers, in part, due to how almost every other language has array literal syntax. This RFC proposes that (array) be built in to glimmer-vm and not require importing. Motivation Arrays and Objects are not only very common to create, they are essential tools when yielding data out of components. There is alternate motivation to implement literals for arrays and objects, but
#999
Make hash built-in in strict-mode
Make (hash) a built in helper Summary Today, when using gjs/gts/<template>, in order to make objects in a template, folks must import the (hash) helper. Because creating objects is fairly commonplace, this is an annoyance for developers, especially as almost every other language has object literal syntax. This RFC proposes that (hash) be built in to glimmer-vm and not require importing. Motivation Arrays and Objects are not only very common to create, they are essential tools when yielding data out of components. There is alternate motivation to implement literals for arrays and objects, but that
#998
Make fn built-in in strict-mode
Make (fn) a built in helper Summary Today, when using gjs/gts/<template>, in order to bind event listeners, folks must import the (fn) helper. Because partial application is so commonplace, this is a grating annoyance for developers. This RFC proposes that (fn) be built in to glimmer-vm and not require importing. Motivation There is precedence for fn being built in, as all the other partialy-application utilities are already built in. (helper) (modifier) (component) It's historically been the stance that, "If it can be built in userspace, it should be, leaving the framework-y things
#997
Make the `on` modifier built-in in strict-mode
Make {{on}} a built in modifier Summary Today, when using gjs/gts/<template>, in order to bind event listeners, folks must import the {{on}} modifier. Because event listening is so commonplace, this is a grating annoyance for developers. This RFC proposes that {{on}} be built in to glimmer-vm and not require importing. Motivation Given how common it is to use the {{on}} modifier: import { on } from '@ember/modifier'; <template> <button {{on 'click' @doSomething}}> click me </button> <form {{on 'submit' @localSubmit}}> <label {{on 'keydown' @a}} {{on 'keyup' @a}} {{on
#561
Adding Numeric Comparison Operators to Templates
Adding Comparison Operators to Templates Summary Add new built-in template {{lt}}, {{lte}}, {{gt}}, and {{gte}} keywords to perform basic numeric comparison operations in templates, similar to those included in ember-truth-helpers. This RFC is a subset of the changes proposed in #388. Motivation It is a very common need in any sufficiently complex Ember app to perform some numeric comparison operations and often the most convenient place to do it is right in the templates. Because of that, ember-truth-helpers is one of the most installed addons out there, either directly by apps or indirectly by other
-
locks
#560
Adding Equality Operators to Templates
Adding Equality Operators to Templates Summary Add new built-in template {{eq}} and {{neq}} helpers to perform basic equality operations in templates, similar to those included in ember-truth-helpers. This RFC is a subset of the changes proposed in #388. Motivation It is a very common need in any sufficiently complex Ember app to perform some equality operations and often the most convenient place to do it is right in the templates. Because of that, ember-truth-helpers is one of the most installed addons out there, either directly by apps or indirectly by other addons that those apps
-
locks
#389
Dynamic tags in glimmer templates
Dynamic tag names in glimmer templates. Summary With the transition from inner-html semantics to outer-html semantics in components, we lost one feature: Being able dynamically define the tag name of components. I think it was an useful feature and we should find a way to bring it back. Motivation Although not something we use every day, there is a need for some components to have a dynamic tag name. This is most often used for certain low-level presentational components. Take for instance a component named <Panel> that is used to encapsulate some presentation concerns. The
-
chancancode