Released

renderComponent Summary Add a new API to for rendering components into any DOM element. Motivation Building an app from scratch requires a fair amount of boilerplate today, and renderComponent abstracts a minimal API that would allow easy integration of components in other enviroments, such as Astro, or Vitepress, or Storybook, or runtime demos such as JSBin. This also pairs well with RFC#931: JS Representation of Template Tag, in that both features together give folks enough to use Ember without compilation (compilation still recommended for optimizations, however). Detailed design Users would import renderComponent from @ember/renderer (a pre-existing module)

EmberData | SchemaService Summary Upgrades the SchemaService API to improve DX and support new features. Deprecates many APIs associated to the existing SchemaService. Motivation The SchemaService today is primarily a way to rationalize the schema information contained on Models. However, as we experimented with ember-m3, GraphQL, ModelFragments and base improvements to Models we've come to realize this information is both feature incomplete and more wieldy than required. So while building SchemaRecord, we've iterated on these APIs and the associated Schemas to gain confidence in a redesign. This is that redesign. Detailed design The SchemaService Resource Schemas Field Schemas

• runspired

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

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

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

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

v2 App Format Summary This RFC defines a new app format, building off the prior work in v2 Addon format, and is designed to make Ember apps more compatible with the rest of the JavaScript ecosystem. This RFC will define conventions of the app and clearly identify functionality that is considered "compatibility integrations" and could be considered optional in the near future. Motivation When ember-cli was created there was no existing JS tooling that met the needs of the Ember Framework. Over the years we have added more and more developer-friendly conventions to our build system that many

EmberData | Request Service Summary Proposes a simple abstraction over fetch to enable easy management of request/response flows. Provides associated utilities to assist in migrating to this new abstraction. Adds new APIs to the Store to make use of this abstraction. Motivation Serializer lacks the context necessary to serialize/normalize data on a per-request basis This is especially true when performing "actions", RPC style requests, "partial" save requests, and "transactional" saves Often users end up needing to pre-normalize in the adapter in order to supply information contained in either headers or to convert into JSON from other forms

• runspired

Introduce new test helpers for rendering (and re-rendering) that obviate the need for get and set Summary Introduce new testing utilities that remove the need for the use of this.get/this.set in test contexts. This will make rendering tests behave more like application code, and also greatly simplify the process of writing rendering tests in TypeScript since it will remove the need to append type information to this as properties are set. Motivation Current rendering tests require developers to set values on this in order for them to actually be present in the template that gets rendered

• rwjblue

Deprecate AutoLocation Summary Deprecate Ember.AutoLocation and related APIs. In next major version, make history the default location (instead of auto). Motivation In practice, 'auto' will almost always resolve to the 'history' location. By removing the 'auto' location and setting 'history' as the default we're removing some complexity around router location, with no downside for users, since they all get it resolved to history anyway. Background The Ember Router can use different mechanisms to serialize its state. The two common ones are 'history' and 'hash'. There is also a special location called 'auto' which does feature detection, preferring 'history'

• rwjblue

Deprecate {{hasBlock}} and {{hasBlockParams}} in templates Summary Deprecate the {{hasBlock}} and {{hasBlockParams}} properties in templates in favor of the {{has-block}} and {{has-block-params}} keywords. Motivation {{hasBlock}} is a way to check if component has a default block provided to it, and {{hasBlockParams}} is a way to check if that default block has block parameters. They are effectively aliases for calling {{has-block}} and {{has-block-params}} respectively, without providing a block name or with the block name "default". They are also not called, and acts like a template fallback lookup instead. {{! hasBlock and hasBlockParams can be referenced directly

New Browser Support Policy Summary Establishes a new browser support policy for the next major release of Ember and Ember Data. Motivation With Microsoft's recent release of the new Chromium-based Edge browser, which has a compatibility mode for Internet Explorer built in, many frameworks, tools, libraries, and websites have begun finally dropping support for the aging browser. In order to unlock the latest browser features and continue improving the framework as a whole, Ember should also drop support in the next major release. In dropping support for Internet Explorer, we will need a new browser support policy. Until

Ember New Lang Summary This RFC introduces the --lang flag as an option for ember new, ember init, and ember addon commands within the Ember CLI. The feature targets the ember-cli build process -- specifically, when generating the file for the application's entry point at app/index.html. If the flag is used with a valid language code, it will assign the lang attribute in the file's root <html> element to that code. The lang attribute is formally defined within the current HTML5 specification; it is used to specify the base human language of an element

RFC Stages Summary Ember's users should be able to look at an RFC and know more about how close it is to being part of a stable release. This proposal introduces explicit stages for RFCs, covering the steps from the initial draft to the shipped result. Inspired by TC39, these stages are a communication and collaboration tool. They can give the community greater visibility into Ember's development, encourage participation, and improve cross-team coordination. This RFC does not aim to substantially change the existing process, but rather apply labels to what already happens informally. Motivation It can be

• kategengler

Adding Logical Operators to Templates Summary Add new built-in template {{and}}, {{or}} and {{not}} helpers to perform basic logical 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 logical 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 addons that

• locks

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

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

[DATA] findRecord/peekRecord via Identifier Summary Users should be able to peek or find records based on lid. Motivation Apps and Addons making use of Identifiers may wish to peek or find the record for a known identifier. This RFC would allow them to do so. Detailed design A new method signature would be added to findRecord peekRecord and getReference. The existing signatures would not be deprecated at this time. For the case where calling findRecord would result in a request being necessary but either no type or id information being known we would error. This is because there is

• runspired

v2 Addon Format (Embroider Compatibility) Summary This RFC defines a new package format that is designed to make Ember packages (meaning both apps and addons) statically analyzable and more compatible with the rest of the NPM & Javascript ecosystem. This RFC is the first step in stabilizing Embroider as our next-generation build system. Motivation One of the good things about Ember is that apps and addons have a powerful set of build-time capabilities that allow lots of shared code with zero-to-no manual integration steps for the typical user. We have been doing “zero config” since before

Custom Model Class RFC Summary This RFC is a follow-up RFC for #293 RecordData and replaces https://github.com/runspired/rfcs/blob/ember-data-custom-records/text/0000-ember-data-model-factory-for.md#ember-data--modelfactoryfor Create a way for addons and user to define their own implementation of a model class. Adds an instantiateRecord method to Store which would allow addons and ED itself to offer a clean replacement the default DS.Model with a custom Model class. Motivation Allowing Addons to experiment with replacing the default DS.Model implementation (https://github.com/runspired/rfcs/blob/ember-

Contextual Helpers and Modifiers (a.k.a. "first-class helpers/modifiers") Summary We propose to extend the semantics of Handlebars helpers and modifiers such that they can be passed around as first-class values in templates. For example: {{join-words "foo" "bar" "baz" separator=","}} {{!-- ...is functionally equivalent to... --}} {{#let (helper "join-words" separator=",") as |join|}} {{#let (helper join "foo") as |foo|}} {{#let (helper foo "bar") as |foo-bar|}} {{foo-bar "baz"}} {{/let}} {{/let}} {{/let}} <Submit {{on click=(action "submit") mouseenter=(action "highlight") mouseleave=(action "unhighlight") }} /> {{!-- ...is functionally equivalent to... --}} {{#let (modifier "on") as |on|}} {{#let (modifier on click=

• chancancode

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

Summary Currently, incrementally experimenting with Ember Data internals is hard both for addon authors and Ember Data contributors. This RFC rationalizes the internals and establishes clear boundaries for record data storage and manipulation allowing us to expose a public api for addon authors to experiment with. Motivation Externally, addons can customize how apps communicate with the server by implementing the Adapter/Serializer APIs but changing how ED deals with relationships, attribute buckets, rollbacks, dirtyness and similar issues is extremely challenging and impossible without extremely internal hacks. One can look at popular addons like EmberDataModelFragments and see how many private APIs

• igorT

Summary This RFC proposes allowing parameters to be passed to the {{mount}} syntax. Motivation This will enable developers to pass contextual data into routeless engines at runtime, allowing individual engines to be used multiple times through a single application under different contexts. An example could be a dashboard of charts where each chart is a routeless engine. Each chart could be of a different type and would require different data. This RFC would enable the following: {{!-- app/templates/application.hbs --}} {{#each charts as |chart|}} {{mount "chart" type=chart.type data=chart.data}} {{/each}} Detailed design You can see the implementation

Summary This RFC aims to expose a low-level primitive for defining custom components. This API will allow addon authors to provide special-purpose component base classes that their users can subclass from in apps. These components are invokable in templates just like any other Ember components (descendants of Ember.Component) today. Motivation The ability to author reusable, composable components is a core feature of Ember.js. Despite being a last-minute addition to Ember 1.0, the Ember.Component API and programming model has proven itself to be an extremely versatile tool and has aged well over time into

Note: This RFC replaces the closely related RFC for Module Normalization. As discussed in the Alternatives section below, many concepts are shared between the two proposals, but there is also a fundamental difference. Summary Create a unified pattern for organizing and naming modules in Ember projects that is deterministic, extensible, and ergonomic. Motivation Ember CLI's conventions for project layouts and file naming are central to every Ember developer's experience. It's crucial to get both the technical and ergonomic details right. The existing conventions used by Ember CLI have evolved gradually and organically over the years. Ember CLI

• mixonic

Summary This RFC adds a unified way to perform meta-operations on records, has-many relationships and belongs-to relationships: get the current local data synchronously without triggering a fetch or producing a promise notify the store that a fetch for a given record has begun, and provide a promise for its result similarly, notify a record that a fetch for a given relationship has begun, and provide a promise for its result retrieve server-provided metadata about a record or relationship Motivation When we initially designed the Ember Data API for relationships, we focused on consumption and mutation of

Summary Engines allow multiple logical applications to be composed together into a single application from the user's perspective. Motivation Large companies are increasingly adopting Ember.js to power their entire product lines. Often this means separate teams (sometimes distributed around the world) working on the same app. Typically, responsibility is shared by dividing the application into one or more "sections". How this division is actually implemented varies from team to team. Sometimes, each "section" will be a completely separate Ember app, with a shared navigation bar allowing users to switch between each app. This allows teams to work quickly

Summary For Ember Data. Pass through attribute meta data, which includes parentType, options, name, etc., to the transform associated with that attribute. This will allow provide the following function signiture updates to DS.Transform: transform.serialize(deserialized, attributeMeta) transform.deserialize(serialized, attributeMeta) Motivation The main use case is to be able to configure the transform on a per-model basis making more DRY code. So the transform can be aware of type and options on DS.attr can be useful to configure the transform for DRY use. Detailed design Implementing The change will most likely start in eachTransformedAttribute, which gets