Recommended

Summary Introduce block parameters to the Handlebars language to standardize context-preserving helpers, for example: {{#each people as |person|}} {{person.name}} {{/each}} Motivation The Problem There is no idiomatic way to write a helper that preserves context and yields values to its template. This is particularly painful for components which have strict context-preserving semantics. Current workarounds Don't write components that need to yield a value. Problem: This may not be an option. Invent a non-standard per-helper syntax (like {{#with foo as bar}} or {{#each item in items}}) that hook into the undocumented keywords to inject variables....

Summary Enable Subresource Integrity [SRI] checks by default. Motivation To promote the use of SRI in Ember apps as a safe default. Applications should be built with integrity attributes when it is safe to do so. (Unfortunately the main advantage won't be met by default, however confirming one attribute will) This solves having poisoned CDN content: An introduction to JavaScript-based DDoS Detailed design Install ember-cli-sri by default. Applications with relative paths will get SRI. Applications with SRI.crossorigin will get SRI on fingerprint.prepend assets Applications with fingerprint.prepend and origin specified and matching get a...

Summary Unlike Handlebars, HTMLBars parses HTML as it parses a template. Bound attributes are one syntax now possible. For example, this variable color is bound to set a class: <div class="{{color}}"></div> Though traditional HTML attribute syntax should be preserved (using class and not className for example), the default path will be to set attributes as properties on the DOM node. However this happy path has several important exceptions, and results in a few strange edge cases. This rfc will go into detail about the expected behavior without talking about the implementation of attribute on...

Improved Release Process Summary & Motivation ember-cli has followed an ad hoc release process throughout its existence which has made it difficult to know exactly when releases would come out, what features would and would not be supported, and the degree to which it would support existing Ember applications. With the proposal for lockstep SemVer there were ideals of guaranteeing compatibility, which we have mostly met, but that resulted in making decisions of delaying an official 2.X release of ember-cli to avoid additional major version bumps. We propose that we adopt a pattern similar to Ember itself...

Summary A number of Ember framework function calls are no-ops in production. Ember CLI should strip these no-op function invocations from production builds by default. Motivation Removing code that isn't required in production results in smaller and faster applications. Detailed design The following framework function calls will be removed from ember-cli production builds by default: Ember.assert Ember.debug Ember.deprecate Ember.info Ember.runInDebug Ember.warn The API documentation will be updated where necessary to indicate that these function calls will be stripped from production builds. A babel plugin will execute the removal of these...

Summary Ember.js 1.13 will introduce a new API for helpers. Helpers will come in two flavors: Helpers are a class-based way to define HTMLBars subexpressions. Helpers: Have a single return value. Must have a dash in their name. Cannot be used as a block ({{#some-helper}}{{/some-helper}}). Can store and read state. Have lifecycle hooks analogous to components where appropriate. For example, a helper may call recompute at any time to generate a new value (this is akin to rerender). Are a superset of shorthand helpers, the function-based syntax described below. They can do more,...

Summary This RFC proposes extending the app.import API to consume anonymous AMD modules. It accompanies ember-cli PR 5976. Motivation AMD modules come in two flavors: named and anonymous. Anonymous AMD is the more portable distribution format, but it typically requires preprocessing into named AMD before it can be included into an application. /* Anonymous AMD Examples */ // direct value define({ color: 'black' }); // function returning value define(function() { return { color: 'black' }; }); // function returning value, with declared dependencies define(["jquery", "moment"], function(jQuery, moment) { return { injectTime: function() { jQuery('#time-box').html(moment().format('HH:MM')); } } }); /* Named AMD Examples */ // direct value define('my-...

Refining the Release Process Ember balances a desire for overall stability with a desire for continued improvements using a two-pronged approach: General adherence to Semantic Versioning, which means that we don't make breaking changes to public, documented APIs except when the major version changes. A rapid release cycle that allows us to ship additive changes to the framework on a regular, digestible basis. Since Ember 1.0, we have refined this approach: All new public APIs are added using feature flags onto the master branch. Feature flagged features are not included in beta or release builds until they...

Summary This RFC proposes new methods on the adapter to signal to the Ember Data store when it should re-request a record that is already cached in the store. It also proposes a new adapter options object that can be used by to provide instructions to the adapter from the place where the store's find method is called. Motivation Use Cases When it comes to fetching records, there are several different behaviors that users may expect. The behavior that users expect is influenced by unique quirks in their data model, pre-existing expectations based on traditional development models,...

Summary The goal of this RFC is to allow for better component composition and the usage of components for domain specific languages. Ember components can be invoked three ways: {{a-component {{component someBoundComponentName <a-component (coming soon!) In all these cases, attrs passed to the component must be set at the place of invocation. Only the {{component someBoundComponentName syntax allows for the name of the component invoked to be decided elsewhere. All component names are resolved to components through one global resolution path. To improve composition, four changes are proposed: The (component helper will be introduced to close over...

Summary Deprecations and warnings in Ember.js should have configurable runtime handlers. This allows default behavior (logging, raise when RAISE_ON_DEPRECATION is true) to be overridden by an enviornment (Ember's tests), addon, or other tool (like the Ember Inspector). Ember-Data and the Ember Inspector have both requested a public API for changing how deprecation and warning messages are handled. The requirements for these and other requests are complex enough that deferring the message behavior into a runtime hook is the suggested path. Motivation Ember.deprecate and Ember.warn usually log messages. With ENV.RAISE_ON_DEPRECATION all...

Summary Add an instrumentation hook that is available to addons. This enables users to write addons that do things like summarize and report build performance information. see https://github.com/ember-cli/ember-cli/issues/6349 for additional context. see https://github.com/ember-cli/ember-cli/pull/6606 for an experimental implementation. Motivation Build performance is important to users. We want to enable users to: Easily discover which portions of their build are costly; Be able to summarize and report build information in an addon; Be able to write addons that analyze build performance instrumentation so that they can...

Summary This RFC proposes the introduction of a official convention to specify the target browsers and node versions of an application. Motivation Javascript and the platforms it runs on are moving targets. NodeJS and browsers release new versions every few weeks. Browsers auto update and each update brings new language features and APIs. Developers need an easy way to express intention that abstracts them from the ever-changing landscape of versions and feature matrices, so this RFC proposes the introduction of a unique place and syntax to let developers express their intended targets that all addons can use, instead of...

Summary Enable Ember CLI users to opt into using yarn for packagement management. Motivation Ember CLI currently uses the npm command line tool to install dependencies when you run ember install or ember new/ember addon. However, several problems usually arise from npm's semantics. Dependency resolution and install times can be significant enough to disrupt workflows, as well as offline support, non-deterministic, non-flat dependency graphs. Yarn was introduced to the JavaScript community with the intent to provide a better developer experience in these areas: Faster installs Offline support Deterministic dependency graphs Lockfile semantics While Ember CLI users...

Summary Add more illustrative detail to the default Ember Data Adapter Errors. Motivation With a production Ember project, it's common to have many errors of the form "Adapter Error", originating from deep in the Ember Data stack and carrying little context about what the original error cause was. The intent is to add the original request URL, the response code, and some payload information to the default Error message for DS.AdapterErrors. From there Errors can be handled or tracked as normal. Detailed design I've been using something similar to the following Adapter (friendly-error-adapter.js): import...

Summary Introduce [qunit-dom] as a dependency by default in the app and addon blueprints. Motivation Why are we doing this? In a modern Ember application making assertions around the state of the DOM is fundamental to confirming your applications functionality. These assertions are often quite verbose: assert.equal(this.element.querySelector('.title').textContent.trim(), 'Hello World!'); Using the find() helper of @ember/test-helpers we can simplify the DOM element lookup, but the signal-to-noise ratio of the code is still not great: assert.equal(find('.title').textContent.trim(), 'Hello World!'); With qunit-dom we can write much...

Ember CLI Docs Summary This RFC proposes converting the existing Ember CLI website into an Ember app, restructuring the table of contents, replacing a significant portion of the learning material, and inviting community members to participate in writing new content. Motivation The purpose of these changes are to empower new contributors, create a consistent narrative structure, correct outdated information, and lead new readers through an easier learning progression. Ember's public sites are being migrated from Ruby apps to Ember apps in order to improve maintainability and empower new contributors. The CLI docs are currently a Jekyll app. Similar migrations...

Summary contains is implemented on Ember.Array, but [contains was renamed to includes in 2014] (https://github.com/tc39/Array.prototype.includes/commit/4b6b9534582cb7991daea3980c26a34af0e76c6c) this proposal is for contains to be deprecated in favour of an includes method on Ember.Array Motivation Motivation is to stay in line with web standards Detailed design First, implement includes polyfill in compliance with includes spec. Polyfill sample from MDN is: if (!Array.prototype.includes) { Array.prototype.includes = function(searchElement /*, fromIndex*/ ) { 'use strict'; var O = Object(this); var len = parseInt(O.length) || 0; if (len === 0) { return false; } var n = parseInt(arguments[1]) || 0;...

Summary Introduce Ember.String.isHtmlSafe() to provide a reliable way to determine if an object is an "html safe string", i.e. was it created with Ember.String.htmlSafe(). Motivation Using new Ember.Handlebars.SafeString() is slated for deprecation. Many people are currently using the following snippet as a mechanism of type checking: value instanceof Ember.Handlebars.SafeString. Providing isHtmlSafe offers a cleaner method of detection. Beyond that, the aforementioned test is a bit leaky. It requires the developer to understand htmlSafe returns a Ember.Handlerbars.SafeString instance and thus limits Ember's ability to change htmlSafe without further breaking...

Summary With the goal of making significant performance improvements and of adding public API to support use cases long-served by a private API, a new API of factoryFor will be added to ApplicationInstance instances. Motivation Ember's dependency injection container has long supported fetching a factory that will be created with any injections present. Using the private API that provided this support allows an instance of the factory to be created with initial values passed via create. For example: // app/logger/main.js import Ember from 'ember'; export default Ember.Logger.extend({ someService: Ember.inject.service() }); import Ember from...

Summary Make Ember feel less overwhelming to new users, and make Ember applications start faster, by replacing the Ember global with a first-class system for importing just the parts of the framework you need. Motivation ECMAScript 2015 (also known as ES2015 or ES6) introduced a syntax for importing and exporting values from modules. Ember aggressively adopted modules, and if you've used Ember before, you're probably familiar with this syntax: import Ember from "ember"; import Analytics from "../mixins/analytics"; export default Ember.Component.extend(Analytics, { // ... }); One thing to notice is that the entire Ember framework is imported as...

Summary The Ember.K utility function is a low level utility that has lost most of its value today. Motivation Let's start explaining what Ember.K is. It is an utility function to avoid boilerplace code and limit the creation of function instances in Ember's internals. The source code for this API is the following: Ember.K = function() { return this; } In a world of globals, writing somefn: Ember.K was effectively shorter than writing someFn: function() { return this; } and generated fewer function allocations. However with the introduction of ES6 modules and the modularization of Ember in process (#176)...

Summary The goal of this RFC is to remove the data-adapter, injectStore, transforms, and store Ember application initializers that Ember Data injects into apps. The ember-data initializer will not be changed and any code that previously depended on the ordering of these initializers (via the before or after properties on an initalizer) can be changed to use the ember-data initializers for ordering. Motivation The initializers data-adapter, injectStore, transforms, and store have not been used by Ember Data since Apr 8, 2014. However, they are still injected into every Ember app that depends on Ember Data because...

Summary Track unique history location states Motivation The path alone does not provide enough information. For example, if you visit page A, scroll down, then click on a link to page B, then click on a link back to page A. Your actual browser history stack is [A, B, A]. Each of those nodes in the history should have their own unique scroll position. In order to record this position we need a UUID for each node in the history. This API will allow other libraries to reflect upon each location to determine unique state. For example, ember-router-scroll...

Summary We would like to deprecate and remove the arguments passed to the didInitAttrs, didReceiveAttrs and didUpdateAttrs component lifecycle hooks. These arguments are currently undocumented on purpose and considered a private API, imposes an unnecessary performance hit on all components whether they are used or not, and can be easily replicated by the users in cases where they are needed. Motivation In the road leading up to Ember.js 2.0, new lifecycle hooks were introduced to components in order to help users shift to a new mental model, dubbed Data Down Actions Up. The hooks were introduced by name,...

Summary Support for component eventMangers is a seldom used feature and should be deprecated. Motivation We should strive to simplify the Ember API and source code where possible. As the custom eventManager feature is rarely used in apps, we should deprecate it. Detailed design We'll introduce a deprecation warning which will be displayed when a component defines an eventManager property or when canDispatchToEventManager is set to true on EventDispatcher. The warning will have a target version of 3.0. If required, we can create an addon which extends the EventDispatcher allowing for opt-in custom eventManagers in Ember apps....

Summary Introduce syntax for passing in multiple named template blocks into a component, and unify the rendering syntaxes / semantics for blocks/primitives/component-factories passed into a component. This RFC is focused chiefly on bringing named blocks to Ember Components, but it was necessary to define a basic roadmap of functionality for Glimmer Components as well, but keep in mind that some of the Glimmer-centric details may change and should hence be considered non-normative. Motivation There are limitations to composition due to the inability to pass more than one block to a component (or 2 blocks if you...

Summary In order to embrace newer features being added by QUnit (our chosen default testing framework), we need to reduce the brittle coupling between ember-qunit and QUnit itself. This RFC proposes a new testing syntax, that will expose QUnit API directly while also making tests much easier to understand. Motivation QUnit feature development has been accelerating since the ramp up to QUnit 2.0. A number of new features have been added that make testing our applications much easier, but the current structure of ember-qunit impedes our ability to take advantage of some of these features. Developers are...

Summary This RFC proposes to deprecate the prototype extensions done by Ember.String, deprecate the loc method, and moving htmlSafe and isHTMLSafe to @ember/template. Motivation Much of the public API of Ember was designed and published some time ago, when the client-side landscape looked much different. It was a time without many utilities and methods that have been introduced to JavaScript since, without the current rich npm ecosystem, and without ES6 modules. On the Ember side, Ember CLI and the subsequent addons were still to be introduced. Global mode was the way to go, and extending native prototypes...

Summary This RFC proposes the deprecation of the following classes: Ember.OrderedSet Ember.Map Ember.MapWithDefault These classes need to be moved to an external addon given they are private classes and unused in Ember.js itself. Motivation These classes have not been used in Ember itself for a while now. They have always been private but they are used in a few addons, and in particular Ember Data is using them. Transition Path Ember.Map and Ember.MapWithDefault will be deprecated and not extracted, but not before the fix mentioned in the following paragraph is landed in Ember Data....

Summary This RFC aims to solidify the usage of ES2015 Classes as a public API of Ember so that users can begin building on them, and projects like ember-decorators can continue to push forward with experimental Javascript features. This includes: Making the class constructor function a public API Modifying some of the internals of Ember.Object to support existing features and make the usage of ES Classes cross-compatible with Ember.Object It does not propose additions in the form of helpers or decorators, which should continue to be iterated on in the community as the spec itself is...

Summary Solicit feedback on dropping support for IE9, IE10, and PhantomJS. Motivation As Ember heads towards version 3.0, it is a good time to evaluate our browser support matrix. Ember follows Semantic Versioning, and we consider browser compatibility to be under the umbrella of those guarantees. In other words, we will continue to support whatever browsers we officially support in Ember 3.0 until Ember 4.0. We want to make this decision on the basis of the browsers that our community still needs to support, while weighing that against the costs we bear as a community to support...

Summary The testing story in Ember today is better than it ever has been. It is now possible to test individual component/template combos, register your own mock components/services/etc, build complex acceptance tests, and almost anything else you would like. Unfortunately, there is a massive disparity between different types of tests. In acceptance tests, you use well designed global helpers to deal with async related interactions; whereas in integration and unit tests you are forced to manually deal with this asynchrony. emberjs/rfcs#232 introduced us to QUnit's nested modules API, made integration and unit testing modular,...

Deprecate Function.prototype.on, Function.prototype.observes and Function.prototype.property Summary This RFC proposes to deprecate Function.prototype.on, Function.prototype.observes and Function.prototype.property Motivation Ember has been moving away from extending native prototypes due to the confusion that this causes users: is it specifically part of Ember, or JavaScript? Continuing in that direction, we should consider recommending the usage of on (@ember/object/evented), observer (@ember/object) and computed (@ember/object) as opposed to their native prototype extension equivalents. We go from two ways to do something, to one. eslint-plugin-ember already provides this as...

Summary Introduce {{@foo}} in as a dedicated syntax for a component's template to refer to named arguments passed in by the caller. For example, given the invocation {{hello-world name="Godfrey"}} and this component template in app/templates/components/hello-world.hbs: Hello, {{@name}} Ember will render "Hello, Godfrey". Motivation Currently, the way to access named arguments passed in from the caller is to reference {{name}} in the template. This works because when Ember creates the component instance, it automatically assigns all named arguments as properties on the component instance. The first problem with this approach is that the...

Summary Introduce a low-level "flag" to remove the automatic wrapper <div> for template-only components (templates in the components folder that do not have a corresponding .js file). In other words, given there is NO app/components/hello-world.js and there exists app/templates/components/hello-world.hbs which contains the following markup: Hello world! When this template-only component is invoked as {{hello-world}} with the flag unset or disabled (i.e. today's semantics), Ember will render: <div id="ember123" class="ember-view">Hello world!</div> When the flag is...

Summary Introduce a low-level "flag" to remove the automatic wrapper <div> around Ember apps and tests. Motivation In Ember applications today, applications are anchored to some existing HTML element in the page. Usually, this element is the <body> of the document, but it can be configured to be a different one when the application is defined, passing a CSS selector to the rootElement property: export default Ember.Application.extend({ rootElement: '#app' }); However, whatever the root is, the application adds another <div> wrapper that is not required anymore. It's a vestigial remainder of...

Summary Install ES5 getters for computed properties on object prototypes, thus eliminating the need to use this.get() or Ember.get() to access them. Before: import Object, { computed } from '@ember/object'; const Person = Object.extend({ fullName: computed('firstName', 'lastName', function() { return `${this.get('firstName')} ${this.get('lastName')}`; }) }); let chancancode = Person.create({ firstName: 'Godfrey', lastName: 'Chan' }); chancancode.get('fullName'); // => 'Godfrey Chan' chancancode.set('firstName', 'ʎǝɹɟpo⅁'); chancancode.get('fullName'); // => 'ʎǝɹɟpo⅁ Chan' let { firstName, lastName, fullName } = chancancode.getProperties('firstName', 'lastName', 'fullName'); After: import Object, { computed } from "@ember/object"; const Person = Object.extend({ fullName: computed('firstName', 'lastName', function() { return `${this.firstName} ${this....

Block let template helper Summary Introduce the let template helper in block form. Motivation The goal of this RFC is to introduce a let template helper that allows to create new bindings in templates. The design of this helper is similar to with, but without the conditional rendering of the block depending on the values passed into the helper. While the conditional semantics of with are coherent with the other built-in helpers like each and if, users often find this unexpected. The fact that only the first positional parameter of with controls whether the block is rendered might also...

Summary Promote the private API {{-in-element}} to public API as {{in-element}}. Motivation Sometimes developers need to render content out of the regular HTML flow. This concept is often also called "portals". Some components like dropdowns and modals use this technique to render stuff close to the root of the page to bypass CSS overflow rules. Some apps that are embedded into static pages even use this technique to update parts of the page outside the app itself. This need need has been covered by solutions developed in the user space but it was so common that glimmer baked...

Make jQuery optional Summary For the past Ember has been relying and depending on jQuery. This RFC proposes making jQuery optional and having a well defined way for users to opt-out of bundling jQuery. Motivation Why we don't need jQuery any more One of the early goals of jQuery was cross-browser normalization, at a time where browser support for web standards was incomplete and inconsistent, and Internet Explorer 6 was the dominating browser. It provided a useful and convenient API for DOM traversal and manipulation as well as event handling, that hid the various browser differences and...

Deprecation of Ember.Logger Summary This RFC recommends the deprecation and eventual removal of Ember.Logger. Motivation There are a variety of features of Ember designed to support old browsers, features that are no longer needed. Ember.Logger came into being because the browser support for the console was inconsistent. In some browsers, like Internet Explorer 9, the console only existed when the developer tools panel was open, which caused null references and program crashes when run with the console closed. Ember.Logger provided methods that would route to the console when it was available. With Ember 3.x, Ember...

RFC (Request for Comments) Process Update Summary Refine the Ember RFC process and have it apply to all Ember teams. Motivation The Ember community has been using the RFC process to great effect over the last few years. Proposals by both Core and community members are discussed and refined with the result coming out much stronger. During this time, the community and the core teams have identified shortcomings of the RFC process as well as new requirements, which this RFC intends to address: Confusion between emberjs/rfcs and ember-cli/rfcs The Ember project currently has two separate RFC processes...

Summary Beginning the transition to deprecate the fallback behavior of resolving {{foo}} by requiring the usage of {{this.foo}} as syntax to refer to properties of the templates' backing component. This would be the default behavior in Glimmer Components. For example, given the following component class: import Component from '@ember/component'; export default Component.extends({ init() { super(...arguments); this.set('greeting', 'Hello'); } }); One would refer to the greeting property as such: <h1>{{this.greeting}}, Chad</h1> Ember will render "Hello, Chad". To make this deprecation tractable, we will provide a codemod for migrating templates. Motivation Currently,...

Angle Bracket Invocation Summary This RFC introduces an alternative syntax to invoke components in templates. Examples using the classic invocation syntax: {{site-header user=this.user class=(if this.user.isAdmin "admin")}} {{#super-select selected=this.user.country as |s|}} {{#each this.availableCountries as |country|}} {{#s.option value=country}}{{country.name}}{{/s.option}} {{/each}} {{/super-select}} Examples using the angle bracket invocation syntax: <SiteHeader @user={{this.user}} class={{if this.user.isAdmin "admin"}} /> <SuperSelect @selected={{this.user.country}} as |Option|> {{#each this.availableCountries as |country|}} <Option @value={{country}}>{{country.name}}</Option> {{/each}...

array helper Summary This RFC proposes to add an array template helper for creating arrays in templates. The helper would be invoked as (array arg1 ... argN) and return the value [arg1, ..., argN]. For example, (array 'a' 'b' 'c') would return the value ['a', 'b', 'c']. Motivation Objects (or hashes) and arrays are the two main data structures in JavaScript. Ember already has a hash helper for building objects, so it makes sense to also include an array helper for building arrays. Detailed design The design is straightforward and mirrors the design of the hash helper. In particular, the important thing...

Deprecation of Ember.copy and Ember.Copyable Summary This RFC recommends the deprecation and eventual removal of Ember.copy and the Ember.Copyable mixin. Motivation A deep-copy mechanism is certainly useful, but it is a general JavaScript problem. Ember itself doesn't need to offer one, especially one that Ember itself isn't using internally. This function and its accompanying mixin arrived with SproutCore, a long time ago, and are not used by Ember itself, even though they currently reside in @ember/object/internals. ember-data uses Ember.copy to do deep-copies. However, the ember-data team finds...

Summary The aim of this RFC is to deprecate the component's isVisible property. It is not used by Ember internally and left undefined unless manually set. It's poorly documented and component visibility it better managed in template space rather than JS. Motivation Setting the isVisible property on a component instance as a way to toggle the visibility of the component is confusing. The majority of its usage predates even Ember 1.0.0, and modern Ember applications already completely avoid using isVisible in favor of simpler conditionals in the template space. In addition, when isVisible is used today...

Ember Data Filter Deprecation Summary Deprecate the store.filter API. This API was previously gated behind a private ENV variable that was enabled by the addon ember-data-filter. Motivation The filter API was a "memory leak by design". Patterns exist with no-worse ergonomics that have better performance and do not incur memory leak penalties. While the change in ergonomics for end consumers in minimal, the change to ember-data is substantial. The code for this feature required significant amounts of confusing internal plumbing to ensure that filters were rerun every time any form of mutation (update, addition, deletion)...

Deprecate Usage of Ember Evented in Ember Data Summary Ember.Evented functionality on DS.Model, DS.ManyArray, DS.Errors, DS.RecordArray, and DS.PromiseManyArray will be deprecated and eventually removed in a future release. This includes the following methods from the Ember.Evented class: has, off, on, one, and trigger. Additionally the following lifecycle methods on DS.Model will also be deprecated: becameError, becameInvalid, didCreate, didDelete, didLoad, didUpdate, ready, rolledBack. Motivation The use of Ember.Evented is mostly a legacy from the pre 1.0 days of Ember Data when events were a core part of the Ember Data programming...

Summary Deprecate all use of: Ember Globals Resolver (looks up a class via a global namespace such as "App") Creation of a Global Namespace (var App = Ember.Namespace.create();) Ember.TEMPLATES array <script type="text/handlebars" data-template-name="path/to/template"> Use of any of the above should trigger a deprecation warning, with a target of version 4.0 Motivation Over the past years we have transitioned to using Ember-CLI as the main way to compile Ember apps. The globals resolver is a holdover and primarily facilitates use of Ember without Ember-CLI. The Globals Resolver...

Deprecate .sendAction Summary In old versions of Ember (< 1.13) component#sendAction was the only way for a component to call an action on a parent scope. In 1.13 with the so called closure actions a more intuitive and flexible way of calling actions was introduced, yielding the old way redundant. Motivation With the new closure actions being the recommended way, component#sendAction is not even mentioned in the guides. With the goal of simplifying the framework I think we should remove what is not considered the current best practice. Closure actions have been available since 1.13....

Native Class Constructor Update Summary Update the behavior of EmberObject's constructor to defer object initialization. Motivation Using native class syntax with EmberObject has almost reached full feature parity, meaning soon we'll be able to ship native classes and begin recommending them. This will do wonders for the Ember learning story, and will bring us in line with the wider Javascript community. However, early adopters of native classes have experienced some serious ergonomic issues due to the current behavior of the class constructor. The issue is caused by the fact that properties passed to EmberObject.create are assigned to...

Deprecate Ember.merge in favor of Ember.assign Summary The goal of this RFC is to remove Ember.merge in favor of using Ember.assign. Motivation Ember.assign has been around quite awhile, and has the same functionality as Ember.merge. With that in mind, we should remove the old Ember.merge, in favor of just having a single function. Detailed design Ember will start logging deprecation messages that tell you to use Ember.assign instead of Ember.merge. The exact deprecation message will be decided later, but something along the lines of: Using `Ember.merge` is deprecated. Please use...

RFC to move the Ember community chat to Discord Summary Encourage the Ember community to adopt Discord for real-time chat (vs Slack or other options). Motivation Real-time chat is essential to the function of online communities, particularly in open source. Chat fosters an informal, interactive style of communication that is important for building relationships, sharing community norms, coordinating on projects, and brainstorming ideas. The Ember community predominantly uses a Slack instance as the gathering place of choice. While we have benefited enormously from Slack, there are significant downsides as well. Loss of History Because we use Slack's...

Ember 2018 Roadmap RFC Summary This RFC sets the Ember 2018 Roadmap. This year’s goals are to: Improve communication and streamline decision-making, and empower new leaders. Finish the major initiatives that we’ve already started. Ship a new edition, Ember Octane, focused on performance and productivity. Motivation This document is a distillation of multiple sources: The 2018 Community Survey. Community #EmberJS2018 blog posts, authored in response to our call for posts. Discussion on https://discuss.emberjs.com Deliberations among the Ember core teams. The goal of the RFC is to align the Ember community around a set of...

Summary Deprecate computed overridability and computed().readOnly() in favor of read-only computeds as the default. Motivation Computed properties have existed in Ember long before class syntax and native accessors (getters and setters) were readily available, and as such they have a few notable behavioral differences. As we move toward adopting native class syntax and using a decorator-based form of computeds, it makes sense to reconcile these differences so that users can expect them to work the same as their native counterparts. The main and most notable difference this RFC seeks to deprecate is computed overridability (colloquially known as...

Summary Deprecate computed().volatile() in favor of undecorated native getters and setters. Motivation computed().volatile() is a commonly misunderstood API. On its surface, declaring a computed as volatile causes the computed to recalculate every time it is called. This actually works much like native, undecorated accessors do on classes, with one key difference. Volatile properties are meant to respresent fundamentally unobservable values. This means that they swallow notification changes, and will not notify under any circumstances, and that when setting a volatile value the user must notify manually: const Foo = EmberObject.extend({ bar: computed({ get() { return this._value; } set(key,...

Element Modifier Manager Summary This RFC proposes a low-level primitive for defining element modifiers. It is a parent to the Element Modifiers RFC. Motivation Ever since Ember 1.0 we have had the concept of element modifiers, however Ember only exposes one modifier; {{action}}. We also do not provide a mechanism for defining your own modifiers and managing their life cycles. As pointed out in the original Modifiers RFC we should expose the underlying infrastructure that makes element modifiers possible. Based on our experience, we believe it would be beneficial to open up these new primitives to the wider...

Summary Deprecate the computed .property() modifier which can be used to add dependent keys to computed properties. Motivation Currently, computed properties can use the .property modifier to add dependent keys to a computed after the computed has been declared: foo: computed('strings', { get() { return this.strings.filter(s => s.includes(this.filterText)); } }).property('filterText') In most cases, this ability is redundant, since the dependent keys can be moved into the original computed declaration and be equivalent: foo: computed('strings', 'filterText', { get() { return this.strings.filter(s => s.includes(this.filterText)); } }) The one exception is in the case of...

Remove jQuery by default Summary This RFC proposes deprecating those public APIs that are coupled to jQuery, and to finally remove them (with an optional backport), so Ember apps will be built by default without bundling jQuery. While RFC294, which is already implemented, provides a way to opt out of jQuery, the intention of this RFC is to push this a step further and essentially move from the current "included by default, allow opt out" strategy to "excluded by default, allow opt in". In that way it is not meant as a replacement of the previous RFC, but rather as...

Ember Data Packages Summary This documents presents the proposed public import path changes for ember-data, and moving ember-data into the @ember-data namespace. Motivation Reduce Confusion & Bike Shedding Users of ember-data have often noted their confusion by the existence of both direct and "god object" (DS.) style imports for modules from ember-data. The documentation currently uses primarily the DS. style, and users have expressed interest and confusion over why the documentation has not been updated to reflect direct imports. Improve The TypeScript Experience Presence of multiple import locations confuses Typescript's autocomplete, symbol resolution, and type...

RouteInfo MetaData Summary The RFC introduces the ability to associate application specific metadata with its corresponding RouteInfo object. This also adds a metadata field to RouteInfo, which will be the return value of buildRouteInfoMetadata for its corresponding Route. // app/route/profile.js import Route from '@ember/routing/route'; import { inject } from '@ember/service'; export default Route.extend({ user: inject('user'), buildRouteInfoMetadata() { return { trackingKey: 'page_profile', user: { id: this.user.id, type: this.user.type } } } // ... }); // app/services/analytics.js import Service, { inject } from '@ember/service'; export default Service.extend({ router: inject('router'), init() { this._super(...arguments); this.router.on('routeDidUpdate', (transition)...

Decorators Summary Native classes are now officially supported in Ember, but currently their usage is very limited. Core Ember features such as computed properties, actions, and service injections have no publicly supported APIs to be used with native class syntax. Decorators provide a way to abstract functionality and improve the developer experience of working with native classes. This RFC outlines the implementation and rollout plan for bringing decorators to Ember's computed properties (and other behavior) for use in native classes. A Note on Decorator Stability Decorators are important to adopting native class syntax. They are a formalization of the...

Tracked Properties Summary Tracked properties introduce a simpler and more ergonomic system for tracking state change in Ember applications. By taking advantage of new JavaScript features, tracked properties allow Ember to reduce its API surface area while producing code that is both more intuitive and less error-prone. This simple example shows a Person class with three tracked properties: export default class Person { @tracked firstName = 'Chad'; @tracked lastName = 'Hietala'; get fullName() { return `${this.firstName} ${this.lastName}`; } } A Note on Decorator Support This RFC proposes a decorator version of tracked properties, and uses this decorator version in most examples, on the...

Render Element Modifiers Summary Element modifiers are a recently introduced concept in Ember that allow users to run code that is tied to the lifecycle of an element in a template, rather than the component's lifecycle. They allow users to write self-contained logic for manipulating the state of elements, and in many cases can be fully independent of component code and state. However, there are many cases where users wish to run some component code when an element is setting up or tearing down. Today, this logic conventionally lives in the didInsertElement, didRender, didUpdate, and willDestroyElement hooks in...

Glimmer Components Summary Glimmer components are a simpler, more ergonomic, and more declarative approach to building components. They represent the sum of multiple years of design and feature work by the community, which stemmed from the original RFCs and discussions surrounding "angle-bracket components". This RFC proposes adding Glimmer components to Ember's public API, and making them the default new app experience in Ember Octane. Attribution The Glimmer components API presented in this RFC was designed in cooperation between @tomdale, @rwjblue, @krisselden, @pzuraq, and others. First, a Bit of History As components became the standard for Single Page Apps...

Deprecate Route render APIs Summary This RFC proposses the deprecation of Route#render, Route#renderTemplate and named {{outlet}} APIs. The following deprecation message will be emitted upon usage of render or renderTemplate: The usage of `renderTemplate` is deprecated. Please see the following deprecation guide to migrate. and The usage of `render` is deprecated. Please see the following deprecation guide to migrate. The following will be compile time deprecation for named outlets: Please refactor `{{outlet <NAME>}}` to a component <SOURCE_INFO>. Motivation These APIs are largely holdovers from a time where components where not as prominent in...

Deprecate Application Controller Router Properties Summary This RFC proposes the deprecation of ApplicationController#currentPath and ApplicationController#currentRouteName. Motivation These APIs are no longer needed as the RouterService now has RouterService#currentPath and RouterService#currentRouteName. These fields are only ever present on the application controller which is a weird special casing that we would like to remove. Additionally, it's likely that there are very few if any consumers of this API as it is not documented. Transition Path If you are reliant on ApplicationController#currentPath and ApplicationController#currentRouteName you can get the same functionality from the RouterService to migrate, inject...

Website Redesign Summary The Ember homepage has been the same for a number of years, and while it's served us well in the past, it's been somewhat stale for a long time. For people who aren’t involved in the day-to-day of Ember development, it’s easy to miss just how well the framework has kept up over the years. This redesign aims to modernize, update and improve all things website, so that the impression we give the general public matches reality. Tremendous thank you to our friends at EmberMap for stepping up to fund and...

Restructuring the Guides Table of Contents Summary As our favorite framework has grown and changed a lot over the past few years, so have our Ember.js Guides! This project aims to use the excellent work that has been done by hundreds of contributors and arrange it in a way that provides a natural learning flow for today’s Ember.js developers. Motivation With Octane coming down the line, and an influx of fresh attention, it’s more important than ever to consider Ember's overall learning experience. It's time for a shift. The current structure and flow of...

Forwarding Element Modifiers with "Splattributes" Summary This is a small amendment to RFC #311 "Angle Bracket Invocation" and RFC #373 "Element Modifier Manager" to clarify how the "splattributes" feature interact with element modifiers. Motivation RFC #311 introduced the angle bracket component invocation feature. Aside from the syntatic differences, the angle bracket invocation syntax enabled passing HTML attributes to components, which can then be applied the underlying HTML element(s) in the component's layout using the ...attributes "splattributes" syntax. For example, given the following invocation: <FooBar class="foo-bar" /> …and the following layout for the FooBar component: <...

Decorator Support Summary Move forward with the Decorators RFC via stage 1 decorators, and await a stable future decorators proposal. Motivation The recently merged Decorators RFC contained an explicit condition: That it was premised on decorators moving from stage 2 in the TC39 process to stage 3. If this were to not happen, the original RFC stipulates that a followup (this RFC) should be created to clarify whether or not we should move forward with decorators while they remain in stage 2, and how we would do so. This RFC proposes that we do so. As discussed in the original,...

Deprecate {{with}} Summary The {{with}} helper has always had slightly confusing conditional semantics, this was one of the motivators for introducing the easier to understand {{let}} helper. Now that {{let}} exists, the remaining use case for using {{with}} is for its unique conditional semantics. These conditional semantics can be cleanly represented with a combination of {{let}} and {{if}} statements so we should deprecate {{with}}. Motivation The difference between {{let}} and {{with}} is with how they handle conditional arguments. The {{let}} helper's block content is always rendered, regardless of its parameters. In contrast, {{with}} only renders its main block when...

Contribution Guides Summary This RFC proposes the creation of an official Contribution Guide that aims to improve the discoverability of Ember-related projects that require help by the community and outlines the general contribution workflow for these projects. Motivation In the past year alone, 43, 34, 29, 81 and 31 people made contributions to the core framework library, the Ember CLI, Ember’s Data library, the source for the official framework Guides, and the project website, respectively. An already impressive amount of developers decided to dedicate their time and effort to contribute to Ember - a project, that has been actively...

Deprecate {{partial}} Summary Partials are an old Ember construct that have no benefits and many downsides when compared to modern Ember components. We should deprecate them in favor of components. Motivation Partials have a number of downsides when compared with components: They are hard to reason about as they inherit the scope of the calling template They perform poorly in comparison to components Partials should have no place in modern Ember applications, components should always be preferred. Once removed, Ember's API will become smaller and more consistent. Detailed design We'll create an AST transform in packages/ember-template-...

Injection Parameter Normalization Summary Normalize on passing the owner as the first parameter to the constructor for the following built in framework classes: GlimmerComponent EmberComponent Service Route Controller Helper Along with the following Ember Data classes: Model Adapter Serializer Transform Terminology Explicit injections are injections which are defined in the class body using the inject APIs: import Component from '@ember/component'; import { inject as service } from '@ember/service'; export default Component.extend({ store: service(), }); The are explicit because they don't require any knowledge of the system to outside of the class itself to know they exist. Implicit injections are...

Nested Invocations in Angle Bracket Syntax Summary Create a syntax for invoking components nested inside of directories in angle-bracket syntax. The invocation <AppIcons::Warning> refers to the component app/components/app-icons/warning.js when using the default resolver, and looks up component:app-icons/warning in the container. Motivation Today's angle-bracket syntax conversion guide says this: This has been an acceptable interim step as we have worked on completing the work of revamping the component model, but it's a source of incoherence (and a reported adoption blocker for some apps) in the Ember...

Angle Bracket Invocations For Built-in Components Summary RFC #311 introduced the angle bracket component invocation syntax. Many developers in the Ember community have since adopted this feature with very positive feedback. This style of component invocation will become the default style in the Octane edition and become the primary way component invocations are taught. However, Ember ships with three built-in components – {{link-to}}, {{input}} and {{textarea}}. To date, it is not possible to invoke them with the angle bracket syntax due to various API mismatches and implementation details. This RFC proposes some small amendments to these APIs and...

Yieldable Named Blocks Summary This RFC amends #226 (named blocks) to finalize the syntax of named blocks and reduce the scope of the feature. Motivation The original named blocks RFC (#226) defined a mechanism for passing multiple blocks to a component, as well as semantics for capturing the block in JavaScript. Since #226, RFC #311 (angle bracket invocation) repurposed the original syntax for invocation. <Tab> <@header></@header> </Tab> In #226, the above syntax passed a named block called @header to the Tab component. RFC #311 repurposed that syntax to mean "invoke the...

@classic Decorator Summary Add a set of warnings for users who adopt native class syntax with EmberObject base classes, and a @classic decorator which can be used to disable these warnings on a per-class basis. Motivation As we've added native class support to Ember and moved forward with Ember Octane, it's become increasingly clear that there are still a number of strange behaviors, edge-cases, and other issues with adopting native class syntax and extending from EmberObject. These issues include: The timings of init and constructor, and how the two can interact through a class hierachy in...

{{fn}} Helper Summary This RFC introduces a new helper, {{fn}}, to allow clear argument passing for functions in templates. Motivation The current action helper has a lot of implicit and confusing behavior that is different than the Octane and post Octane programming model. To understand the complexity of action there are many complex behaviors including: Argument partial application (currying) this context binding send checks for Component and Controllers At build time the action helper currently is passed through an AST transform to explicitly bind the this to be deterministic at runtime. This is a private API where the outputted Glimmer...

{{on}} Modifier Summary Add an {{on}} modifier for adding event listeners to elements. Motivation Currently, there are two ways to bind event listeners to elements in Ember templates with built-in, official Ember APIs: Use the {{action}} element modifier Use the on*= property bindings Both of these solutions are problematic for a number of reasons. The {{action}} modifier: Uses a non-standard AST transform to pass this in order to bind the context of the template (the component) to the function (typically a component method). This is problematic behavior, not just because of the transform, but because of the implicit...

Tracked Properties Updates Summary During the Ember Octane preview period we encountered some issues with the current design for Tracked Properties that was proposed and accepted in RFC 410. The primary issues were specifically around interop between tracked properties, computed properties, and autotracking, with a few extra issues and inconsistencies surrounding these. This RFC seeks to fix these issues and provide a new interop path. Motivation During the preview for Octane, we've encountered a few issues with tracked properties: Computed property autotracking interop was too aggresive, and resulted in breaking changes in existing applications. When users need to use...

Component Templates Co-location Summary We propose to place a component's JavaScript file (the class) and its template in the same directory on the file system. Today: app ├── components │ ├── just-class.js │ ├── my-widget.js │ ├── nested │ │ └── another-widget.js │ └── ... ├── models │ └── ... ├── routes │ └── ... ├── services │ └── ... ├── templates │ ├── components │ │ ├── just-template.hbs │ │ ├── my-widget.hbs │ │ ├── nested │ │ │ └── another-widget.hbs │ │ └── ... │ ├── some-route.hbs │ └── ... └── ... Proposed: app ├── components │ ├── just-class.js │ ├── just-template.hbs │ ├── my-widget.hbs │ ├── my-widget.js │ ├── nested │ │ ├── another-widget.hbs │ │ └── another-widget.js │ └── ... ├── models │ └── ... ├── routes │ └── ... ├── services │ └── ... ├── templates │ ├── some-route.hbs │ └── ... └── ... Motivation Today, a component's JavaScript file is located in the app/components...

Deprecate support for mouseEnter/Leave/Move Ember events Summary Deprecate support for mouseenter, mouseleave and mousemove events in Ember's EventDispatcher. This affects the corresponding event handler methods (mouseEnter() {}) in Ember components and {{action "some" on="mouseenter"}}. Motivation Ember's EventDispatcher handles "Ember events" by attaching listeners to the app's root element and relying on the events bubbling up to that element (aka event delegation). There they are processed and invoke any matching Ember.Component event handler method with the same (camel-cased) method as the event type. Same for element-space {{action}} modifiers. Note: for a "Deep Dive...

Deprecate disconnectOutlet Summary This RFC deprecates Route#disconnectOutlet because it has no use case given #418. Motivation Route#disconnectOutlet is intended to be used in conjunction with Route#render. When we wrote #418 we should have also deprecated Route#disconnectOutlet because it is primarily used to teardown named outlets setup by Route#render. For all intensive this is just an addendum to #418. Transition Path The transition path is the same to the one outlined in #418. Since the migration path for the named outlets is to use components, a developer would need to wrap the component in a conditional...

Handlebars Strict Mode Summary In this RFC, we propose a set of changes to Ember's variant of Handlebars that are aimed at codifying best practices, improving clarity and simplifying the language. Together, these changes are bundled into a "strict mode" that Ember developers can opt-into. In contrast, the non-strict mode (i.e. what developers are using today) will be referred to as "non-strict mode" in this RFC. This RFC aims to introduce and define the semantics of the Handlebars strict mode, as well as the low-level primitive APIs to enable it. However, it does not...

Deprecate default Adapter and Serializer fallbacks Summary As part of Project Trim, https://github.com/emberjs/data/issues/6166, this deprecates the fallback and default adapter and serializer across ember-data including: deprecate -default serializer fallback in Store.serializerFor deprecate adapter.serializer and adapter.defaultSerializer instance property fallbacks (which currently default to -json-api). deprecate store.defaultAdapter instance property (which defaults to -json-api) and the -json-api adapter fallback behavior in adapterFor. deprecate record.toJSON instance method since this relies on the -json serializer. Motivation The adapter and serializer packages provide reference implementations and base classes that are not...

Provide @model named argument to route templates Summary Allow route templates to access the route's model with @model in addition to this.model. Before: {{!-- The model for this route is the current user --}} <div> Hi <img src="{{this.model.profileImage}}" alt="{{this.model.name}}'s profile picture"> {{this.model.name}}, this is a valid Ember template! </div> {{#if this.model.isAdmin}} <div>Remember, with great power comes great responsibility!</div> {{/if}} After: {{!-- The model for this route is the current user --}} <div> Hi <img src="{{@model....

Deprecate getWithDefault Summary Deprecate support for getWithDefault in Ember's Object module (@ember/object) – both the function and the class method – because its expected behaviour is confusing to Ember developers. Motivation The problem with getWithDefault is that its behaviour is confusing to Ember developers. The API will only return the default value when the value of the property retrieved is undefined. This behaviour is often overlooked when using the function where a developer might expect that null or other falsy values will also return the default value. Given the JavaScript language will soon (currently in Stage 3) give us the...

Edition detection Summary Introduces a mechanism that an application can use to specify which Edition of Ember it intends to target. This RFC will define: How to specify the edition that the application is using How other packages (addons, codemods, etc) can detect the applications intended edition What the edition should be used for Motivation As Ember approaches its first edition (see emberjs/rfcs#364) various addons need to modify their behavior based on the edition that is being used. An initial implementation (done without RFC) used the setEdition method from @ember/edition-utils inside the application or addon's...

@cached Summary Add a @cached decorator for memoizing the result of a getter based on autotracking. In the following example, fullName would only recalculate if firstName or lastName is updated. class Person { @tracked firstName = 'Jen'; @tracked lastName = 'Weber'; @cached get fullName() { return `${this.firstName} ${this.lastName}`; } } Motivation One of the major differences between computed properties and tracked properties with autotracking in Octane is that native, autotracked getters do not automatically cache their values, where computed properties were cached by default. This was an intentional design choice, as the memoization logic for computed properties was actually more costly, on average, than...

Destroyables Summary Adds an API for registering destroyables and destructors with Ember's built in destruction hierarchy. class MyComponent extends Component { constructor() { let timeoutId = setTimeout(() => console.log('hello'), 1000); registerDestructor(this, () => clearTimeout(timeoutId)); } } The API will also enable users to create and manage their own destroyables, and associate them with a parent destroyable. class TimeoutManager { constructor(parent, fn, timeout = 1000) { let timeoutId = setTimeout(fn, timeout); associateDestroyableChild(parent, this); registerDestructor(this, () => clearTimeout(timeoutId)); } } class MyComponent extends Component { manager = new TimeoutManager(this, () => console.log('hello')); } Motivation Ember manages the lifecycles and lifetimes of many built in constructs, such...

Autotracking Memoization Summary Provides a low-level primitive for memoizing the result of a function based on autotracking, allowing users to create their own reactive systems that can respond to changes in autotracked state. import { tracked } from '@glimmer/tracking'; import { createCache, getValue } from '@glimmer/tracking/primitives/cache'; let computeCount = 0; class Person { @tracked firstName = 'Jen'; @tracked lastName = 'Weber'; #fullName = createCache(() => { ++computeCount; return `${this.firstName} ${this.lastName}`; }) get fullName() { return getValue(this.#fullName); } } let person = new Person(); console.log(person.fullName); // Jen Weber console.log(count); // 1; console.log(person.fullName); // Jen Weber console.log(count); // 1; person.firstName = 'Jennifer'...

Helper Managers Summary Provides a low-level primitive for defining helpers. Motivation Helpers are a valuable template construct in Ember. They have a number of benefits that come from having their lifecycle being managed by the template and container, including: Behavior can be self-contained. Some APIs need to run at multiple points in time based on a template's lifecycle, such as for a plugin that needs to be setup on initialization and torn down upon destruction. Doing this in components via lifecycle hooks usually forces users to split their API across multiple touch points in a component, which...

JavaScript Helper Invocation API Summary This RFC proposes a new API, invokeHelper, which can be used to invoke a helper definition, creating an instance of the helper in JavaScript. // app/components/data-loader.js import Component from '@glimmer/component'; import Helper from '@ember/component/helper'; import { invokeHelper } from '@ember/helper'; class PlusOneHelper extends Helper { compute([number]) { return number + 1; } } export default class PlusOneComponent extends Component { plusOne = invokeHelper(this, PlusOneHelper, () => { return { positional: [this.args.number], }; }); } {{this.plusOne.value}} Motivation As Ember has evolved, the framework has been developing a model of reactive, incremental computation. This model is oriented around templates,...

Add Prettier Summary This RFC proposes adding Prettier to the blueprints that back ember new and ember addon. Motivation Using Prettier removes the ever present and ongoing stylistic debates that tend to happen on teams. Prettier is incredibly freeing for both developers and reviewers of a codebase. The developer can author in whatever format they find easiest to type out, avoiding needless wasted time trying to get that indentation just right, and either setup an automated "format on save" operation in their editor or use a quick command line invocation to --fix all files at once. This dove tails very...

RouterService#refresh Summary Add a refresh method to the router service that calls refresh on all currently active routes, or refreshes the descendents of the active route referred to by the pivot route name provided as an argument. Motivation We want to be able to call refresh on all currently active routes, or a subset of them, from a centralized service or from a component. As a side benefit, we will be able to do this without relying on the send api, which is being discussed as a possible deprecation in RFC 632. This enables us to get the latest...

Facilitate customization of setupTest* functions Summary Provide a default and convenient way for each project to customize the setupApplicationTest, setupRenderingTest, and setupTest functions from RFC #268 and RFC #232. The app and addon blueprints will be updated to create a file at tests/helpers/index.js where those functions will be wrapped and exported, creating a local place to edit for each type of test setup. Tests generated using ember generate will import the setup functions from that file. Motivation Projects often need to customize setup for every test. For example, in acceptance tests, it is often necessary to override...

Replace terms blacklist & whitelist in Ember CLI Summary Ember.js prides itself (rightly) on being an inclusive framework. To further improve on this, we should remove the terms "blacklist" and "whitelist" with more neutral replacements. Motivation The terms "blacklist" and "whitelist" can be considered racially insenstive. While the origin of these terms in this context is not in itself racially motivated, the fact that in todays context it can be considered racially insensitive has been discussed frequently - see for example here, here or here. Other projects have already taken similar steps, for example Go, Android, curl or PHPUnit. These...

Add ember-page-title to the app blueprint Summary Add ember-page-title to the default blueprint for new Ember apps as a way to provide improved out-of-the-box (OOB) accessibility for Ember applications. Motivation This RFC is part of the work made by the Ember.js Accessibility Strike Team to ensure that newly created ember apps have no accessibility issues. Users with assistive technology rely on the page title to know if they are on the correct page of a website. Adding this addon will provide developers a simple solution to achieve the WCAG Success Criterion 2....

{{unique-id}} helper Summary Add a new built-in template helper {{unique-id}} for generating unique IDs. See pre-RFC issue #612 Motivation When working with HTML it is very common to need to create and reference DOM IDs that are unique within the HTML document. Classic Ember components provide the elementId attribute which can be used to construct unique ids within classic components, but elementId is not available within Glimmer components or route templates. There are several common use cases where a developer may need to generate a unique ID for use in a template: Associating label and input...

Stop Leaking Implementation Details of Built-in Components Summary In order to stop leaking implementation details of built-in components, we propose to: Deprecate importing the following modules @ember/component/checkbox @ember/component/text-area @ember/component/text-field @ember/routing/link-component Deprecate accessing the following properties on the Ember global Ember.Checkbox Ember.LinkComponent Ember.TextArea Ember.TextField Ember.TextSupport (already private, no import path available) Ember.TargetActionSupport (already private, no import path available) Deprecate calling reopen or reopenClass on the classes and mixins listed above, whether they were obtained through an import or the Ember global Deprecate...

Deprecate tryInvoke Summary Deprecate support for tryInvoke in Ember's Utils module (@ember/utils) because native JavaScript has optional chaining for developers to use as an alternative solution. Deprecating tryInvoke will help to reduce Ember API redundancy. Motivation In most cases, Function arguments should not be optional, but in the rare occasion that a Function argument is intentionally optional by design, we can use native JavaScript's optional chaining as a solution. Deprecating tryInvoke will help to reduce Ember API redundancy. Transition Path Ember will start logging deprecation messages for tryInvoke usage. Deprecation text: Using tryInvoke has been deprecated. Instead,...

Deprecate transition methods of controller and route Summary The methods transitionTo and replaceWith of the Route and the methods transitionToRoute and replaceRoute of Controller should be deprecated. Existing methods transitionTo and replaceWith of RouterService should be used instead. Motivation The main motivation is to reduce public API surface related to routing. This will make the required refactoring of router easier as soon as the methods have been removed. The router is known to be poorly documented and underspecified. Especially timing of the different APIs has been an issue in the past. Some timing related bugs are open since years.¹ The...

Implicit Injection Deprecation Summary This RFC seeks to deprecate implicit injections on arbitrary Ember Framework objects. This is commonly done via owner.inject in an intializer or instance-initializer. A prevalent example of implicit injection is found in ember-data injecting their default @ember-data/store into all @ember/routing/route and @ember/controller factory objects. Here is a pruned example of how this looks. // app/initializers/store-inject.js export function initialize(application) { application.inject('route', 'store', 'service:store'); application.inject('controller', 'store', 'service:store'); } export default { name: 'store-inject', initialize, }; export default class PostRoute extends Route { // This proposal...

Deprecate Old Manager Capabilities Summary Deprecate older capabilities versions from the various manager APIs. Motivation In the 3.x cycle, Ember introduced a series of new low-level APIs for managing template constructs: Component managers Modifier managers Helper managers These APIs were expected to evolve more quickly than the higher level APIs they enabled, and they have in fact done so. They do this via the capabilities mechanism, where users can specify a version of capabilities that they want. This allows Ember to change these APIs as needs evolve, as long as the prior capabilities can still be maintained. Maintaining...

Deprecate using {{attrs}} in templates Summary The {{attrs}} object in templates is an alternative way for users to reference named arguments directly in a template. {{attrs.foo}} {{! is equivalent to }} {{@foo}} It was a legacy API that existed prior to named arguments being introduced in Ember, and has continued to be supported via a template transform for some time. This RFC proposes that we deprecate this functionality in favor of directly using named arguments. Motivation The {{attrs}} syntax was from a previous iteration of the concepts that eventually became named argument syntax. Now that named arguments exist in the framework,...

Deprecate passing classBinding and classNameBindings as arguments Summary In Ember today, it is possible to pass classBinding and classNameBindings as arguments to a component when invoked with curly syntax. {{some-component classNameBindings="foo:truthy:falsy"}} These arguments are merged into the class attribute on the class, regardless of whether or not the component is a classic component which contains the classNameBindings logic. It is also fully possible to accomplish with template syntax in alternative ways, so this RFC proposes deprecating them. Motivation classBinding and classNameBindings are Classic component APIs for manipulating the class name of the element that wraps the...

Deprecate Array Observers Summary Deprecate array observers, and all associated APIs and events, including: Methods: addArrayObserver removeArrayObserver arrayContentWillChange arrayContentDidChange Events: @array:before @array:change Motivation Array observers are a feature of Ember's custom array implementations. They are implemented using a completely different system than standard observers, and historically served different goals, namely integrating array changes with Ember's classic push-based reactivity system. With autotracking, the reactivity system was rewritten in a way that didn't require array observers at all, so there is no longer a need for them internally. In addition, array observers are fundamentally synchronous. They...

Deprecate Component Positional Arguments Summary We propose to deprecate invoking the <LinkTo> component with positional arguments, in favor of the equivalent named arguments introduced in RFC #459. We also propose to deprecate the (query-params) helper, which is only needed when invoking the <LinkTo> component with positional arguments. Motivation In modern Ember, the idiomatic way to invoke most components is to use the angle bracket syntax along with the named arguments @ syntax. On the other hand, curly invocations are now reserved for "helper-like" and "control-flow" components. The <LinkTo> built-in component started...

Add eslint-plugin-qunit to ember-cli blueprint Summary This RFC proposes adding eslint-plugin-qunit to the blueprints that back ember new and ember addon. Motivation Ember apps and addons already come with a number of linting plugins targeting various areas of the code: ember-template-lint - handlebars best practices eslint - general JavaScript best practices eslint-plugin-ember - Ember best practices eslint-plugin-node - Node best practices prettier - automatic styling (as a result of a recent RFC) But there's an important aspect of Ember apps that is not yet targeted by specialized linting: testing. Test code can easily...

Deprecate Octane Optional Features Summary Deprecate the optional features introduced in the transition to Ember Octane. This specifically refers to the optional features which are required for an Ember application to set the octane edition: application-template-wrapper template-only-glimmer-components Motivation The Octane edition consisted for the most part of backwards compatible changes, a design choice inline with the Ember philosophy of introducing new features and changes while ensuring that there is an upgrade path. Editions are about introducing a new programming model side-by-side with the old one, allowing users to adopt the changes gradually. As...

Deprecate jQuery Integration Optional Feature Summary Deprecate the jquery-integration optional feature flag. Motivation jQuery integration has been a part of Ember since the beginning. When Ember was first released, a variety of browser features had not been standardized yet, and jQuery was a necessary tool for creating code that worked in all major browsers. This is no longer the case, and Ember is no longer internally reliant on jQuery. That said, jQuery is still a useful library with many plugins, and that many developers use. Adding jQuery to an Ember application is still completely possible, and not deprecated by...

Deprecate the Ember Global Summary Deprecate the Ember global, window.Ember, and replace it fully with import Ember from 'ember'; Motivation The Ember global, available at window.Ember (or globalThis.Ember in all environments) is a mostly legacy API from before Ember adopted native ES modules. Modern Ember apps do not use the global, and in general it is mostly used by legacy code and occasionally in examples. However, it still exists and remains undeprecated. The primary motivation for deprecating the global object is for tree shaking purposes. Because the global object is assigned eagerly to window.Ember whenever Ember...

Reduce API Surface of Built-In Components Summary In order to reduce the API surface of the built-in <LinkTo>, <Input> and <Textarea> components, we propose to deprecate all named arguments on these components except the following: <LinkTo> @route @model @models @query @replace @disabled @current-when @activeClass @loadingClass @disabledClass <Input> @type @value @checked @insert-newline @enter @escape-press <Textarea> @value @insert-newline @enter @escape-press Motivation This is a follow-up to RFC #671 and shares the same high-level motivations and historical context. Detailed design The following...

Official TypeScript Support Summary TypeScript has become a key part of the front-end development ecosystem over the past several years, and powers many of the best developer experiences in the front-end ecosystem. Ember was a relatively early TypeScript adopter for its internals, and there is widespread usage in the ecosystem with community support from the Typed Ember team, but to date Ember has not provided “out of the box” or official support for authoring apps or addons in TypeScript. This RFC declares our intent to officially support TypeScript as a peer to JavaScript, in a way which makes...

DOM Element descriptor interface for test helpers Summary @ember/test-helpers' DOM helpers and qunit-dom accept either a selector or an Element as their DOM element descriptor, which is a pretty common pattern. This RFC proposes an interface that generalizes the notion of a DOM element descriptor that @ember/test-helpers' DOM helpers, qunit-dom, and other similar test support libraries in the Ember ecosystem can support, so page object implementations such as fractal-page-object and ember-cli-page-object can implement the interface and integrate cleanly and ergonomically with these test support libraries. Motivation In this RFC...

Semantic Versioning for TypeScript Types Note on Authoritative Source The living specification to which Ember is committed lives at www.semver-ts.org. The text below represents the RFC as it was merged as part of Ember.js’ RFC process. However, per the text below, this is not the authoritative form of this specification: If these recommendations are adopted, the Detailed Design section shall be published to a dedicated, standalone repository to ease linking to it (including by TypeScript packages beyond the Ember ecosystem, if they find it useful, as we hope they will!). Accordingly, the text below represents the...

EmberData | Deprecate Non Strict Relationships Summary Deprecates various shorthands for defining a belongsTo or hasMany relationship that create ambiguity, cause expensive runtime lookups, or hinder static analysis. Motivation Deprecating these shorthands allows us to provide better tooling, remove the bulky and expensive code necessary to determine the outcomes of these shorthands at runtime, and in the process clarify and simplify relationship behaviors in the documentation. Further, it allows us to align our own internal usage of "relationship meta" with the API put forward in RFC#487 Custom Model Classes. Detailed design Three shorthands are proposed to be deprecated, with the...

EmberData | Deprecate Non Strict Types Summary Deprecates when the type for a record provided by a user differs from the resolved type, thereby removing the need to configure ember-inflector to treat types as uncountable in order to use plural model names, and removing the dasherization constraint. Motivation Today, ember-data normalizes user supplied type or modelName anywhere it is encountered so that it will match the type we expect to provide to ember's resolver to lookup and create instances of Model/Adapter/Serializer. In practice, this resulted in a convention of singularized, dasherized modelName arguments and type fields...

EmberData | Deprecate Legacy Imports Summary Deprecates import DS from "ember-data"; and individual imports within the ember-data package in favor of the imports provided by RFC#395 packages Motivation These imports are just a legacy remnant we no longer need. Detailed design Lint rules and a codemod already exist to migrate users to using packages, and have been available now for over a year. The ember-data-packages plugin for ember-cli-babel would be updated so that users would receive a deprecation when importing from the legacy paths. If required for legacy global or DS import a runtime...

Deprecate Ember.assign Summary Now that Ember is dropping support for IE11, we no longer need Ember.assign as a polyfill since Object.assign is available in all browsers that Ember v4.x supports (CanIUse, MDN). Motivation The polyfill is no longer necessary, as well as being another Emberism that can be removed. Apps and addons can use Object.assign or object destructuring depending on their browser support targets. Transition Path The transition path is relatively simple: apps that use Ember 4.x will replace Ember.assign with Object.assign, and apps and addons that use or support Ember 3....

Rename inject import to service Summary Currently, in order to use a service in any framework class you can do it like this: import { inject } from '@ember/service'; export class MyComponent extends Component { @inject router; } However, it is very common to actually alias this import to service, like this: import { inject as service } from '@ember/service'; export class MyComponent extends Component { @service router; } This RFC proposes to actually provide this as a service import directly. Motivation You cannot properly/easily use editor autocompletion to import @service. Even in the guides, inject is aliased to service (see: https://guides.emberjs.com/...

Default Helper Manager Summary Anything that can be in a template has its lifecycle managed by the manager pattern. Today, we have known managers for @glimmer/component, @ember/helper, etc. But what happens when the VM encounters an object for which there is no manager?, such as a plain function? This RFC proposes a default behavior for those unknown scenarios when it comes to helpers. Motivation The addon, ember-could-get-used-to-this demonstrated that it's possible to use plain functions for helpers and modifiers. And since Ember 3.25, helpers can be invoked directly from value references,...

Deprecate Bower Support Summary This RFC proposes to deprecate the following Bower APIs: Blueprint::addBowerPackageToProject Blueprint::addBowerPackagesToProject Project::bowerDependencies (not public, but used in several addons) Project::bowerDirectory (not public, but used in several addons) This RFC also proposes to deprecate building Bower packages, coming from /bower_components by default. Motivation While Bower is still maintained, it's recommended to use an alternative package manager instead (npm, Yarn, pnpm, …). This is also the official recommendation of the Bower team. Additionally, Ember CLI stopped emitting a bower.json file since v2.13.0 and the Ember Guides recommend to not use...

Deprecate Implicit Record Loading in Routes Summary This RFC seeks to deprecate and remove the default record loading behaviour on Ember's Route. By consequence, this will also deprecate and remove the default store on every Route. This behaviour is likely something you either know you have or do not know but it may be occuring in your app. export default class PostRoute extends Route { beforeModel() { // do stuff } afterModel() { // do stuff } } In this example, the model hook is not defined. However, Ember will attempt to try a few things before rendering this route's template. If there is a store...

Author Built-In Blueprints in TypeScript Summary In order to support both TypeScript and JavaScript as official languages in Ember, we should enable blueprints to be written in TypeScript and (optionally) transformed to JavaScript. We should also convert all of the existing built-in blueprints to TypeScript to take advantage of this new functionality and lay the groundwork for future TypeScript inclusion efforts. Motivation Ember CLI's generators are a foundational part of Ember itself. They are one of the first elements of the developer experience that Ember prides itself on, and continue to be an essential part of the...

TypeScript Adoption Plan Summary RFC #0724 commits Ember to officially supporting TypeScript and articulates an overall philosophy for what official support means. This RFC defines a detailed implementation plan for officially supporting TypeScript in Ember, including: the SemVer policies Ember packages should adopt, following RFC #0730: supported TypeScript versions the "breaking change" policy an Edition support policy how we will migrate users from depending on the @types definitions on DefinitelyTyped to Ember packages test infrastructure to catch regressions early updates to Ember CLI to support TypeScript release "channel" testing analogous to Ember's existing feature flag system for runtime code...

Element Modifiers Summary This RFC introduces the concept of user defined element modifiers and proposes adding ember-modifier to the blueprint that back ember new, providing an officially-supported path for using modifiers out of the box. This RFC supersedes the original RFC #353 "Modifiers". Motivation Ember Octane introduced Glimmer Components as a replacement for Classic Components. They are simpler, more ergonomic, and more declarative. In contrast with Classic Components, Glimmer Components don't have any element/DOM based properties or hooks giving access to DOM. This was an intentional move as component backing class gets disconnected from DOM manipulation....

Add tracked-built-ins Summary This RFC proposes adding tracked-built-ins to the blueprint that back ember new. Motivation Ember had historically shipped EmberArray and EmberObject as well as Map and Set implementations to make it easy to work with those types in a reactive way. tracked-built-ins does the same for the auto-tracking era. Autotracking (Ember's reactivity model) is one of the key features of Ember Octane. tracked-built-ins fills the gap in the reactivity mental model we have today when it comes to tracking updates in data structures. Today, @tracked decorator may be...

Public API for Type-Only Imports Summary Introduce public import locations for type-only imports which have previously had no imports, and fully specify their public APIs for end users: Owner, with RegisterOptions and Factory Transition RouteInfo and RouteInfoWithAttributes Outline Motivation Detailed design Owner RegisterOptions Factory FactoryManager FullName getOwner and setOwner Transition RouteInfo RouteInfoWithAttributes Resolver How we teach this Owner Transition, RouteInfo, and RouteInfoWithAttributes Blog post Drawbacks Alternatives Unresolved questions Motivation Prior to supporting TypeScript, Ember has defined certain types as part of its API, but without public imports, since the types were not designed to be imported, subclassed, etc....

Standardize use of scripts in package.json for common tasks Summary This change encourages developers to use scripts in package.json for certain commands when working with Ember applications, rather than using global Ember CLI commands like ember serve or focusing on npm/yarn. This aligns Ember with norms in the JavaScript community, and helps in reducing the confusion around Ember-specific commands. Motivation In many JavaScript projects, the following commands are very common: npm start npm test These scripts are defined in the package.json of Ember apps, however, Ember's documentation tells developers to run these commands instead:...

Deprecate array prototype extensions Summary This RFC proposes to deprecate array prototype extensions. Motivation Ember historically extended the prototypes of native Javascript arrays to implement Ember.Enumerable, Ember.MutableEnumerable, Ember.MutableArray, Ember.Array. This added convenient methods and properties, and also made Ember arrays automatically participate in the Ember Classic reactivity system. Those convenient methods increase the likelihood of becoming potential roadblocks for future built-in language extensions, and make it confusing for users to onboard: is it specifically part of Ember, or Javascript? Also with Ember Octane, the new reactivity system, those classic observable-based methods are no longer...

EmberData Cache V2.1 Summary A rename of the Cache (RecordData) API with new restrictions and additional amendments to the accepted #461 RecordData V2 spec. These alterations will further simplify EmberData while increasing its flexibility and extensibility. In turn, this increased flexibility provides the backbone for further design and exploration of new capabilities such as QueryCache, GraphQL and an enhanced SSR and Rehydration Mode. Motivation We originally designed RecordData as a public formalization of one of the core responsibilities of InternalModel. This allowed applications that had needed to reach into private API to achieve criticial feature support a public avenue...

Deprecate ember-mocha Summary This RFC proposes to officially deprecate ember-mocha. Consequently, this would also deprecate support for ember-mocha when generating test blueprints. Both ember-source and ember-data have logic to determine the presence of ember-mocha in order to use the appropriate test blueprints. Motivation ember-mocha has been unmaintained for a while now. The last release was published on Jun 16, 2019. It also seems this release is not compatible with Ember v4. Instead of letting ember-mocha slowly fade away, it feels better to officially deprecate it and clearly communicate this to the community....

Deprecate @ember/error Summary The @ember/error package is just a re-export of the native Error and is therefore unnecessary. Motivation Removal of unnecessary code keeps the codebase cleaner and simplifies developer burden. Transition Path There is no use case for this anymore. A simple codemod can convert current uses to the native Error class. How We Teach This Remove @ember/error from docs. Drawbacks You'll have to run a codemod to resolve existing usage. However, this is trivial and will actually simplify user code. Alternatives None. Unresolved questions None....

pnpm support Summary Enable Ember CLI users to opt into using pnpm for package management. Motivation pnpm is a popular alternative to both npm and yarn that prioritizes correctness, especially for peerDependencies and monorepos. pnpm has very active maintainance, support, and financial funding. Their website states that pnpm is: Fast: pnpm is up to 2x faster than the alternatives Efficient: Files inside node_modules are cloned or hard linked from a single content-addressable storage Supports monorepos: pnpm has built-in support for multiple packages in a repository Strict: pnpm creates a non-flat node_modules by default, so code...

Deprecate Support for Travis CI Summary This RFC proposes to officially deprecate support for generating a Travis CI config file when creating a new app or addon. Motivation Since Travis CI announced the end of its unlimited support for open-source projects, most of the (the entire?) Ember community has switched over to using GitHub Actions instead. This basically leaves the .travis.yml files in the app and addon blueprints unused. Even though the maintenance cost of keeping these files around is pretty low, not having to maintain them would be even better. It would make PRs like this slightly...

Treat Safari as an Evergreen Browser Summary Safari's release cadence has increased as well as relevant-device compatibilty. This RFC proposes an amendment to the browser support policy (introduced in RFC#685) to treat Safari the same as Chrome and FireFox for Desktop and Mobile devices. Motivation Treating Safari differently from other browsers is no longer necessary due to changes in release cadence. Only being able to adjust Safari support with an RFC and at major versions is unnecessary overhead. Detailed design Ember v6 will support Safari based on usage statistics, the same as other browsers we support. How...

Deprecate non-co-located components. Summary Deprecates classic component layout pods component layout Once this deprecation is implemented, only the following will be allowed: co-located components gjs / gts components Motivation These older component layouts force build tooling to keep a lot of resolution rules around, and makes it hard for codemods and other community tooling to effectively work across folks' projects. Transition Path There are two types of paths to migrate off the old layouts use a currently supported multi-file layout (keeping separate js, ts, and hbs files) migrate the component entirely to the latest component format, gjs,...

Deprecate named inject export from @ember/service Summary As of ember-source@4.1 (and RFC#752), inject is an old alias that's no longer needed Motivation import { service } from '@ember/service' makes more sense than import { inject as service } from '@ember/service' This allows us to slim down our public API surface area to more of what's needed. Transition Path Most folks can do a mass find and replace switch from inject as service to just service. An example codemod could look something like this ```js export const parser = 'ts' export default function transformer(file, api) { const...

Deprecate (action) template helper and {{action}} modifier. Summary The (action) template helper and {{action}} modifier was common pre-Octane. Now that we have native classes and the {{on}} modifier, we no longer need to use (action) or {{action}} Motivation Remove legacy code with confusing semantics. This is a part of Deprecating Ember Classic (pre-Octane). Transition Path This was written in the Octave vs Classic cheatsheet that content here Before (pre-Octane) // parent-component.js import Component from '@ember/component'; export default Component.extend({ count: 0 }); {{!-- parent-component.hbs --}} {{child-component count=count}} Count: {{this.count}} // child-component.js import...

EmberData | Deprecate Store extending EmberObject Summary This RFC deprecates the Store extending from EmberObject. All EmberObject specific APIs included. Motivation There are two motivations: First, extending EmberObject is vestigial. The Store makes no use of any EmberObject API, not even for use with Ember's container or service injection. Second, in order to support any Ember version, support any non-Ember framework, and support EmberData running in non-browser environments we want to remove unnecessary coupling to the Ember framework. Detailed design Instead of deprecating every EmberObject method, we will feature flag the Store extending EmberObject at the module level....

Deprecate app-prefix, app-suffix, tests-prefix, and tests-suffix Summary ember-cli addons can use their contentFor method to emit arbitrary Javascript into many places. This RFC proposes deprecating and removing several of them: app-prefix app-suffix tests-prefix tests-suffix vendor-prefix vendor-suffix Motivation All of these assume there's going to be one "app" bundle, one "vendor" bundle, and one "tests" bundle. But those assumptions are now nonsense, given code-splitting and builds that can directly evaluate the module graph in the browser. They are also seldom used based on code searches on emberobserver.com:...

Vanilla Prettier Setup in Blueprints Summary This RFC proposes to migrate to a vanilla Prettier setup in the blueprints, instead of running Prettier via ESLint and Stylelint. Motivation Because we run Prettier via ESLint and Stylelint, we only run the files these linters support through Prettier - Using a vanilla Prettier setup, would format all files Prettier supports, ensuring even more consistency in projects Less dependencies in the blueprints - eslint-plugin-prettier and stylelint-prettier would not be needed anymore The Prettier team recommends running Prettier directly, and not via linters: Running Prettier directly is faster than running Prettier via ESLint...

Default globals for strict mode Summary This RFC aims to introduce platform-native globals as allowed defaults in strict-mode components, allowing for more intuitive usage, and less "know how the compiler works" This is an ergonomics-focused RFC. The proposed changes today can be polyfilled via globalThis['...'] accesses. Motivation Early on there was a bug in the build tools of strict-mode components that allowed any global to be used components. This was dangerous, as strict-mode allows use of all in-scoped variables to be used in all valid syntax positions in the template, and while this is...