RFCs that need your help

Summary Adds command line completion (tab completion) to ember-cli that fills in partially typed commands by the user and suggests available sub commands or options. (from now on i will refer to "strings in the command line" as "cli-commands" and "generate" and "new" as unprefixed "commands") Motivation With all the already existing commands and especially all blueprints, plus the fact that any addon can add even more blueprints to your tool kit, users can get overwhelmed. Currently, when you want to execute a specific task and you don't quite know the correct cli-command you have to...

Summary It should be possible to white- and/or blacklist addons in EmberApp. Motivation If there are two (or more) EmberApps, it's very likely that not all applications need all addons. E.g. if there is a main page application and one application for embeddable widgets, the main page might need all sorts of addons like ember-modal-dialog which adds completely useless bytes to widgets javascript and css files for the widgets. Other addons may add useless initializers or other things that have runtime performance penalties for no benefit. Detailed design When EmberApp ctor gets passed a blacklist...

Summary Give blueprint generators the ability to clean up old files. Motivation We want to eliminate the noise of having old files laying after updating ember-cli using ember init. Detailed design We'd like an API for blueprints to delete files instead of only create. It would be essentially syntactic sugar for removing the file yourself in an afterInstall hook. It would be a returned array on the blueprint's index.js. // ember-cli/bluprints/blah/index.js module.exports = { // ... get oldFilesToRemove() { return [ 'brocfile.js', 'LICENSE.MD', 'testem.json' ]; } }; How We Teach This The guides could use this addition...

Summary The goal of this RFC is to solidify the next version of the mechanism that ember-cli uses to build final assets. It will allow for a more flexible build pipeline for Ember applications. It also unlocks building experimental features on top. It is a backward compatible change. Motivation The Packager RFC submitted by Chad Hietala is a little over 2 years old. A lot of things have changed since then and it requires a revision. The current application build process merges and concatenates input broccoli trees. This behaviour is not well documented and is a tribal knowledge. While...

Summary In order to largely reduce the brittleness of tests, this RFC proposes to remove the concept of artificially restricting the resolver used under testing. Motivation Disabling the resolver while running tests leads to extremely brittle tests. It is not possible for collaborators to be added to the object (or one of its dependencies) under test, without modifying the test itself (even if exactly the same API is exposed). The ability to restrict the resolver is not actually a feature of Ember's container/registry/resolver system, and has posed as significant maintenance challenge throughout the lifetime of ember-test-...

Ember Data Record Links & Meta Summary Enable users to associate links and meta information with individual records in a manner accessible via the template. Motivation Sometimes users have meta or links information to associate with a specific record. Users of the json-api specification will commonly understand this information as belonging to an individual resource. While ember-data allows for this information to exist on relationships, it does not allow for it to exist on records, which has to this point been a glaring omission for users of json-api and similar specifications. Detailed design In keeping with the...

Deprecate Ember Utils & dependent Computed Properties Summary This RFC proposes the deprecation of the following methods: compare isBlank isEmpty isEqual isNone isPresent typeOf As well as computed properties that rely on these methods: notEmpty empty none Once deprecated, these methods will move to an external addon to allow users to still take advantage of the succinctness these utility methods provide. Motivation To further Ember's goal of a svelte core and moving functionality to separate packages, this RFC attempts to deprecate a few utility methods and extract them to their own addon. A part from the aforementioned goal, in...

ember-data | modelFactoryFor Summary Promote the private store._modelFactoryFor to public API as store.modelFactoryFor. Motivation This RFC is a follow-up RFC for #293 RecordData. Ember differentiates between klass and factory for classes registered with the container. At times, ember-data needs the klass, at other times, it needs the factory. For this reason, ember-data has carried two APIs for accessing one or the other for some time. The public modelFor provides access to the klass where schema information is stored, while the private _modelFactoryFor provides access to the factory for instantiation. We provide access to the class...

Dynamic tag names in glimmer templates. Summary With the transition from inner-html semantics to outer-html semantics in components, we lost one feature: Being able dynamically define the tag name of components. I think it was an useful feature and we should find a way to bring it back. Motivation Although not something we use every day, there is a need for some components to have a dynamic tag name. This is most often used for certain low-level presentational components. Take for instance a component named <Panel> that is used to encapsulate some presentation concerns. The...

Router Helpers Summary This RFC introduces new router helpers that represent a decomposition of functionality of what we commonly use {{link-to}} for. Below is a list of the new helpers: {{url-for}} {{root-url}} {{is-active}} {{is-loading}} {{is-transitioning-in}} {{is-transitioning-out}} This represents a super set of the functionality provided by Ember Router Helpers which has provided this RFC that confidence that a decomposition is possible. This RFC does not deprecate {{link-to}} or {{query-params}}. These deprecations will come in the form of a deprecation RFC. Motivation {{link-to}} is the primary way for Ember...

Summary This deprecates the string-based lookup API for associating a custom component manager with a corresponding base class. import EmberObject from '@ember/object'; import { setComponentManager } from '@ember/component'; export default setComponentManager('basic', EmberObject.extend({ //... })) Instead, you must pass a factory function that produces an instance of the custom manager: import EmberObject from '@ember/object'; import { createManager } from './basic-manager'; import { setComponentManager } from '@ember/modifier'; export default setComponentManager(createManager, EmberObject.extend({ // ... })); Where createManager is: export function createManager(owner) { return new BasicManager(owner); } Motivation There are several motivators: A string-based API is not friendly when it comes to tree shaking....

Ember Data | Identifiers Summary Identifiers provides infrastructure for handling identity within ember-data to satisfy requirements around improved caching, serializability, replication, and handling of remote data. This concept would parallel a similar structure proposed for json-api resource identifier lid property drafted for version 1.2 of the json-api spec. In doing so we provide a framework for future RFCs and/or addons to address many common feature requests. Motivation This groundwork RFC represents the union of a diverse set of motivations, each of which is discussed below in no particular order of importance, outside of the first. This...

Summary This RFC sets the plan for Ember Data's medium term development, on the path towards modularizing the library. We expect the following immediate design and implementation work to take between one and two quarters. The main goals are: Increase approachability of the library for both the users and contributors Increase iteration speed and stability Enable shedding of legacy layers Increase flexibility and lay the foundation for future improvements Background and Motivation Ember Data needs to continue to evolve with Ember and the wider Javascript ecosystem and provide a modern first class data handling support. Moreover, we want to...

Singleton Record Data Summary Ensures that RecordData can be implemented as a singleton, eliminates several redundant APIs that creeped into the original implementation, and simplifies the method signatures of RecordData APIs by using Identifiers. Motivation RecordData is the data-cache primitive for information given to ember-data, and while a cache-per-entity setup is sometimes desired, a singleton cache offers opportunities for performance optimization and improved feature sets. Current default RecordData, and InternalModel which it replaced are examples of cache-per-entity strategies. Our original intent when discussing RecordData was for it to be possible to be implemented as...

Record State on Record Data RFC Summary This RFC is a follow-up RFC for #293 RecordData. Add isNew , isDeleted and isDeletionPersisted methods on Record Data that expose information about newly created and deleted states on the record Motivation RecordData handles managing local and server state for records. While the current API surface of RecordData handles most data wrangling needs, as we have used RD internally in ED and in addons we have repeatedly run into the need of knowing whether a record is in a new or a deleted state. The initial version of Record Data made the choice...

Record Data Errors RFC Summary This RFC is a follow-up RFC for #293 RecordData. Exposes the content of Invalid Errors returned by the adapter on Record Data. Motivation Currently Record Data manages and exposes all of the attributes and relationships for a record. However, the initial version of Record Data made the choice to not expose error information in order to limit the scope of the RFC and to give us time to come up with a design. This RFC, together with the Request State RFC, addresses this capability gap. When a user sends a record save request, it...

Request State Service Summary Currently, Ember Data internally uses a complicated state machine abstraction to help records keep track of what state they are in and expose state flags. A lot of those flags try to expose request state. Instead of relying on a complicated inflexible state machine, this RFC proposes exposing a Request State service which would expose inflight and completed requests. Motivation Currently DS.Model has several flags that expose information about either inflight requests or completed requests. isReloading and isSaving expose inflight request state, while isLoaded, isValid, isError, expose state about the last completed request. While these...

Syncing Blueprints Summary I want to use ember-cli-update to keep any blueprint up-to-date. Since ember-cli-update can not possibly contain knowledge of all blueprints, some state must be stored in a project. Motivation Projects like libkit, @glimmer/blueprint, @ember/octane-app-blueprint, and other app replacement blueprints become out-of-date instantly after generation. Tweaks to the blueprints are only beneficial to newly generated apps. Detailed design State storage schema Up until now, ember-cli-update could update apps without any configuration, but in order to handle all blueprints and their options, some state has...

Async Observers Summary Add a way to specify whether or not observers should fire synchronously - that is, immediately after the property they are observing has changed - or asynchronously during the next runloop, along with an optional feature to specify whether observers should default to sync or async. Motivation Observers have been run synchronously in Ember since before v1.0 was released, and for about as long it has been an intention of the core team to eventually make them asynchronous. There are a two main reasons for why triggering observers asynchronously would be better overall: They promote better programming practices....

Ember 2020 Roadmap Summary The purpose of the Ember Roadmap process is to rally the community around a number of shared goals. This post documents those goals for 2020. Since the Ember community cannot predict the future, we cannot be sure that we will achieve all of the individual items enumerated here. Instead, the purpose of this document is to give the community a common purpose to aspire towards. This year our two headline priorities are: Polish the practical and conceptual details of Octane (tracked properties, Glimmer components, related tooling, accessibility, performance and payload improvements). Make Ember easier to try...

Adding Equality Operators to Templates Summary Add new built-in template {{eq}} and {{neq}} helpers to perform basic equality operations in templates, similar to those included in ember-truth-helpers. This RFC is a subset of the changes proposed in #388. Motivation It is a very common need in any sufficiently complex Ember app to perform some equality operations and often the most convenient place to do it is right in the templates. Because of that, ember-truth-helpers is one of the most installed addons out there, either directly by apps or indirectly by other addons that those apps...

Adding Comparison Operators to Templates Summary Add new built-in template {{lt}}, {{lte}}, {{gt}}, and {{gte}} keywords to perform basic numeric comparison operations in templates, similar to those included in ember-truth-helpers. This RFC is a subset of the changes proposed in #388. Motivation It is a very common need in any sufficiently complex Ember app to perform some numeric comparison operations and often the most convenient place to do it is right in the templates. Because of that, ember-truth-helpers is one of the most installed addons out there, either directly by apps or indirectly by other...

Adding Logical Operators to Templates Summary Add new built-in template {{and}}, {{or}} and {{not}} helpers to perform basic logical operations in templates, similar to those included in ember-truth-helpers. This RFC is a subset of the changes proposed in #388. Motivation It is a very common need in any sufficiently complex Ember app to perform some logical comparison operations and often the most convenient place to do it is right in the templates. Because of that, ember-truth-helpers is one of the most installed addons out there, either directly by apps or indirectly by other addons that...

Summary Test waiters have been around in Ember in one form or another since version 1.2.0, and provide a way for developers to signal to the testing framework system that async operations are currently active, when to keep waiting, and when those async operations have completed. This allows the active test to wait during the test in a deterministic fashion, and only proceed once the active async is completed. The current test waiters implementation has a simple but confusing API, and the test waiters themselves lack some key features. This RFC proposes replacing them with a new test...

Improved Ember Registry APIs Summary Introduce a new, object-based API for all registry APIs; deprecate the current string-based microsyntax registry APIs; and introduce a capabilities property to the resolver to safely support existing resolvers. Extend the new API for service and controller injections, and deprecate their microsyntax for namespaced injections. Today the registry APIs are all of shapes roughly like this: getOwner(this).lookup('service:session'); This RFC proposes that they would instead be written like this: getOwner(this).lookup({ type: 'service', name: 'session' }) Service and controller injections which include a namespace currently look like this: class Example...

Interactive New Ember App Creation Summary As part of the effort to make new Ember apps more conformant for digital accessibility requirements at a global scale, this RFC proposes an interactive workflow for new Ember apps. This will also have the benefit of assisting new users who prefer an interactive model of new app creation. Motivation This RFC is the result of analysis and discussion in Ember's accessibility strike team. The overall roadmap for addressing this issue is with a series of RFCs that intend to (independently) offer: a partial resolution to ensuring new Ember apps achieve WCAG Success...

Deprecation Staging Summary Establish a staging system for deprecations that allows Ember and other libraries to roll them out more incrementally. This system will also enable users to opt-in to a more strict usage mode, where deprecations will assert if encountered. The initial stages would be: Available Enabled Motivation Ember has a robust deprecation system that has served the community well. However, there are a number of pain points and use cases that it does not cover very well: Ecosystem Absorption: Generally, deprecations need to be absorbed by the addon ecosystem before they can be absorbed by applications. This...

Tracked Storage Primitives Summary Provide a low level primitive for storing tracked values: let storage = createStorage(); // Set the value of the storage setValue(storage, 123); // Get the value of the storage getValue(storage); Motivation Today, there are two methods for creating a tracked value in Ember apps: The @tracked decorator, which turns class properties into tracked properties Ember.get, which can be used to track a key on an object so that it updates if it is set with Ember.set, or dirtied with notifyPropertyChange. The @tracked decorator is good for cases where there are a known set of mutable...

EmberData | Deprecate Model Reopen Summary Deprecates using reopen to alter clases extending @ember-data/model. Motivation reopen restricts the ability of EmberData to design better primitives that maintain compatibility with @ember-data/model, and is a footgun that leads to confusing incorrect states for users that utilize it. Detailed design The static reopen method on Model will be overwritten to provide a deprecation which once resolved or after the deprecation lifecycle completes will result in reopen throwing an error when used in dev and silently no-oping in production. This deprecation will target 5.0 and not be enabled sooner...

EmberData | Deprecate Accessing Static Fields On Model Prior To Lookup Summary Deprecates when a user directly imports a model extending @ember-data/model and attempts to access one of the static fields containing schema information about attributes or relationships. Motivation Schema descriptors on classes extending @ember-data/model require walking the prototype chain to collect inherited attributes and relationships. This isn't possible until an EmberObject's private proto method has been invoked. Externally, we feel accessing schema information in this manner is a bad practice that should be avoided. Schema information is exposed at runtime via store.modelFor in...

EmberData | Deprecate Helper Functions Summary Deprecates the exported util functions errorsHashToArray errorsArrayToHash and normalizeModelName that were recommended for deprecation by the RFC#395 packages Motivation These utils are a legacy remnant of when parts of the codebase were shared with each other by a DS global. Over time their utility has shrunk and today they no longer align with the direction of error management or type constraints. Detailed design Users would receive a build-time deprecation when importing these methods using the paths specified in RFC#395 packages. They would receive a run-time deprecation when using these methods via...

EmberData | Modernize PromiseManyArray Summary Deprecates reading, mutating or operating on an async hasMany relationship before resolving it's value in the application's Javascript code. Rendering an async hasMany in a template will continue to work as expected. Motivation PromiseManyArray is a promisified ArrayProxy that serves as a fetch wrapper when a user either implicitly or explicitly defines a hasMany relationship as async. It is the synchronous return value when a user access the async relationship on a record instance. For instance, given the following Post model. class Post extends Model { @hasMany('comment' { inverse: null, async: true }) comments } A user...

Summary In TypeScript, the @glimmer/component base class currently has a single Args type parameter. This parameter declares the names and types of the arguments the component expects to receive. This RFC proposes a change to that type parameter to become Signature, capturing more complete information about how components can be used in a template, including their expected arguments, the blocks they accept, and what type of element(s) they apply any received attributes and modifiers to. This RFC is based in large part on prior work by @gossi and on learnings from Glint. Outline Motivation Detailed design InvokableComponentSignature GlimmerComponentSignature...

Asset Import Spec Summary This RFC defines standard semantics for what it means to depend on files that are not JavaScript or CSS, like images, fonts, and other media. It proposes that when your code needs to refer to an asset, you use import.meta.resolve which returns a string that can be used to fetch the asset. class extends Component { myImage = import.meta.resolve('./hello.png'); } <img src={{this.myImage}} /> Motivation Apps and addons often need to refer to images, fonts, etc from within their JS, HBS, CSS, or HTML files. These references need to remain correct...

Ember cookbook proposal Summary Adding a cookbook section to our learning resources will help Ember developers to learn maintainable, accessible patterns for common tasks. Motivation Ember docs in its current state are missing how-to guides that would provide goal-oriented answers / patterns to common problems Ember developers face on a daily basis. For example, if someone wants to learn how to handle a form submission, they would have to look at blog posts. Additionally, many Ember users over the years have requested a cookbook-like resource. Early versions of Ember had a resource like this, but it was removed...

EmberData | Polymorphic Relationship Support Summary Allow setting polymorphic relationships without inheritance and mixins. Deprecate using inheritance and mixins for polymorphic relationships. Target version: 5.0. Motivation Currently, although undocumented and not explicitly supported, you can set polymorphic relationships using two mechanisms: inheritance and mixins. This RFC seeks to lay out an explicitly supported path for polymorphic relationships that composes well with native class usage, eliminates the dependency on instanceof checks and prototype chain walking, and is compatible with the schema service introduced in RFC #487 Example Using Inheritance import Model, { belongsTo, hasMany } from '@ember-data/model'; class TagModel extends Model...

Simplify Schema Definition Service methods in Ember Data Summary This RFC is an amendment to the Custom Model Classes RFC (https://github.com/emberjs/rfcs/pull/487). Based on implementation feedback, we discovered we could simplify the arguments to attributesDefinitionFor and relationshipsDefinitionFor to drop the string argument and always pass in an object. Motivation When implementing a schema service, code ends up easier and cleaner if it does not have to deal with both a raw string and an object. Detailed design The original RFC proposed the following interface: interface SchemaDefinitionService { // Following the existing RD implementation attributesDefinitionFor(identifier: RecordIdentifier | type:...

Return a Promise from Model.save() Summary Model.save() will return a Promise instead of a PromiseProxyMixin, otherwise referred to as a PromiseObject from here on out. Motivation The API documentation already documents the return value as a Promise. Remove dependency on promise proxies Async Consistency - The PromiseObject encourages a usage pattern of sometimes-async, sometimes-sync behavior. We want to reduce zalgo. API consistency - While the PromiseObject proxies properties, the PromiseObject does not proxy methods on the underlying model. For instance, if you try to call a method like destroyRecord on the model, you will get a “not a...

Deprecate RSVP.Promise for native Promise Summary All methods currently returning an RSVP.Promise will return a native Promise. In addition, all documentation will be updated accordingly. Motivation With the removal of IE11 from our build infrastructure and browser requirements, we can now safely remove RSVP.Promise. From the docs: Specifically, it is a tiny implementation of Promises/A+. It works in node and the browser (IE9+, all the popular evergreen ones). RSVP was Ember's polyfill since an early v1.0.0 version during a time when native Promises didn't exist in any browser. In addition, Promises have...

Deprecate blacklist and whitelist build options Summary This RFC proposes to deprecate the blacklist and whitelist build options, in favour of the exclude and include build options. Motivation In RFC 639, the exclude and include build options were introduced. These options provide exactly the same functionality as the blacklist and whitelist build options, but these new terms are more neutral. RFC 639 was implemented and released in Ember CLI v4, which means we should be able to deprecate the old terms in favour of the new ones somewhere in the near future. Transition Path When either the blacklist or the...

Add stylelint to Ember blueprints Summary This RFC proposes adding stylelint to the blueprints that back ember new and ember addon. Motivation Ember app and addons already come with a broad variety of linting plugins targeting various areas of our codebases: ember-template-lint - Handlebars & Ember Templating Best Practices eslint - General JavaScript Best Practices eslint-plugin-ember - Ember JavaScript Best Practices eslint-plugin-node - Node Best Practices eslint-plugin-qunit - QUnit Best Practices RFC prettier - Automated Code Styling RFC With all these amazing tools in place, however, we still have a major aspect of our Ember codebases that are...

EmberData | Deprecate Proxies Summary Deprecates usage of proxy apis provided by Ember.ObjectProxy, Ember.PromiseProxyMixin and Ember.ArrayProxy in favor of Promises, Native Arrays, and Native Proxies where appropriate. Specifically this affects RecordArray AdapterPopulatedRecordArray, ManyArray, PromiseArray, and PromiseRecord but not PromiseBelongsTo. Motivation Historically EmberData built many presentation classes overtop of Framework primitives out of necessity. Native Proxies did not yet exist, Promises were relatively unheard of, and async state management was the Wild West. Today we have better native primitives available to us, affording us the opportunity to significantly simplify these presentation objects and better align them with user expectations...

Deprecate Support for ember-cli-qunit and ember-cli-mocha When Generating Test Blueprints Summary This RFC proposes to deprecate support for ember-cli-qunit and ember-cli-mocha when generating test blueprints. Motivation Both ember-cli-qunit and ember-cli-mocha were deprecated a long time ago in favor of ember-qunit and ember-mocha respectively. Deprecating (and later on, removing) support for both addons would greatly reduce the amount of test blueprints we have in ember-source and ember-data. Transition Path The test-framework-detector.js files in ember-source and in ember-data will be updated...

Introduce a Wildcard Module Import API Summary Introduce import.meta.glob() for use in all Ember apps and addons. Motivation This RFC is siblings with an RFC that deprecates all usage of Ember's traditional AMD infrastructure. That necessarily means we will remove requirejs.entries and requirejs._eak_seen. So we need to explain what you're supposed to use instead if you need to enumerate modules. import.meta.glob() is one answer to that question. Detailed design First, an illustrative example: // If you type this in your app: const widgets = import.meta.glob('./widgets/*.js') // It gets automatically converted...

EmberData | Deprecate Legacy Request Support Summary Deprecates methods on store and model that utilize non-request-manager request paradigms. These methods are no longer recommended in the face of the greater utility of store.request. Deprecates methods on store associated to older request paradigms / the inflexibility of older paradigms. These deprecations would target 6.0. Motivation This RFC is a debt collection. The newer RequestManager paradigm offers a pipeline approach to requests and preserves the context of the request throughout its lifecycle. This newer paradigm solves the issues with limited power and flexibility that the adapter/serializer approach suffered and...

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

Make {{on}} a built in modifier Summary Today, when using gjs/gts/<template>, in order to bind event listeners, folks must import the {{on}} modifier. Because event listening is so commonplace, this is a grating annoyance for developers. This RFC proposes that {{on}} be built in to glimmer-vm and not require importing. Motivation Given how common it is to use the {{on}} modifier: import { on } from '@ember/modifier'; <template> <button {{on 'click' @doSomething}}> click me </button> <form {{on 'submit' @localSubmit}}> <label {{on 'keydown' @a}} {{on 'keyup' @a}} {{on...

Make (fn) a built in helper Summary Today, when using gjs/gts/<template>, in order to bind event listeners, folks must import the (fn) helper. Because partial application is so commonplace, this is a grating annoyance for developers. This RFC proposes that (fn) be built in to glimmer-vm and not require importing. Motivation There is precedence for fn being built in, as all the other partialy-application utilities are already built in. (helper) (modifier) (component) It's historically been the stance that, "If it can be built in userspace, it should be, leaving the framework-y things...

Make (hash) a built in helper Summary Today, when using gjs/gts/<template>, in order to make objects in a template, folks must import the (hash) helper. Because creating objects is fairly commonplace, this is an annoyance for developers, especially as almost every other language has object literal syntax. This RFC proposes that (hash) be built in to glimmer-vm and not require importing. Motivation Arrays and Objects are not only very common to create, they are essential tools when yielding data out of components. There is alternate motivation to implement literals for arrays and objects, but that...

Make (array) a built in helper Summary Today, when using gjs/gts/<template>, in order make arrays in templates, folks must import the (array) helper. Because creating arrays is fairly commonplace, this is an annoyance for developers, in part, due to how almost every other language has array literal syntax. This RFC proposes that (array) be built in to glimmer-vm and not require importing. Motivation Arrays and Objects are not only very common to create, they are essential tools when yielding data out of components. There is alternate motivation to implement literals for arrays and objects, but...

Deprecate TargetActionSupport Summary Deprecate send and the corresponding TargetActionSupport. Motivation These are legacy patterns that are no longer recommended in modern Ember code. The primary way to interact with this system was the now-deprecated {{action}} modifier/helper. The modern approach is to use standard class methods (optionally decorated with @action) and to pass functions directly, following the Data Down, Actions Up (DDAU) pattern. See also: Target Action Support deprecation guide Detailed design This RFC proposes to deprecate and remove the following: TargetActionSupport mixin, specifically the triggerAction method ActionHandler mixin, specifically the send method ActionSupport mixin, specifically the send method...

Built in tracking utilities for common collections Summary This RFC proposes making the set of collections from tracked-built-ins built in to the framework, in a byte-wise opt-in in a brand new package (@ember/reactive) and able to be used without new. Additionally, these APIs can unblock the implementation of RFC#1000: Make array built-in in strict mode and RFC#999: make hash built in in strict mode (but this is not the main focus of this RFC and only could be an outcome). Motivation tl;dr: performance discoverability aiming towards better cohesion Because tracked-built-...

WarpDrive Package Unification Summary Restructure the existing @ember-data/* and @warp-drive/* packages in order to simplify the installation and configuration story while maintaining the benefits of a multi-package architecture. Required packages for a fully functional ember.js experience would be: @warp-drive/core (all the universal basics) @warp-drive/ember (reactivity and inspector integration, ember specific components) @warp-drive/json-api (cache implementation) Additional packages that applications may choose to utilize would be: @warp-drive/utilities @warp-drive/experiments @warp-drive/legacy A few packages would be deprecated, overall existing packages would remain and could still be individually...

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

Deprecating Ember Proxies Summary Now that Native Proxy is available in all supported environments, we can deprecate Ember's custom Proxy handling provided by ArrayProxy, ObjectProxy, and PromiseProxyMixin. Motivation These patterns were introduce to Ember prior to the availability of Native Proxy. Since Native Proxy is now available in all supported environments, we can deprecate these patterns in favor of the native Proxy API. Additionally, we would like to deprecate Mixins in the future necessitating that we first deprecate PromiseProxyMixin. Transition Path There is no direct migration path for these. Code that relies upon this behavior will have to be...

Default Template invisible character Minification Summary Integrate template invisible character minification directly into Ember's template compiler, making the behavior of the ember-hbs-minifier addon available by default for all Ember applications. This will automatically remove unnecessary invisible character from templates while preserving semantic meaning and visual layout, resulting in smaller bundle sizes and improved performance without requiring developer intervention. Motivation HTML templates in Ember applications often contain significant amounts of invisible character that exists purely for developer readability but serves no semantic or visual purpose in the rendered output. This invisible character includes: Leading and trailing spaces, tabs,...

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

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

Summary This has come up in #3699 and EmberTown/ember-hearth/#66. In short, it would be nice for tools that depend on Ember-CLI to be able to read the help output as JSON (for example ember g --help --json). Motivation In our specific use case in Ember Hearth we would like to be able to render a dynamic GUI for some tasks, like generating blueprints. This way we could also include any blueprints added by addons. This will also apply to any other tools interfacing with Ember-CLI. Detailed design We should probably make the internal help-functions...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

First-Class Component Templates Summary Adopt <template> tags as a format for making component templates first-class participants in JavaScript and TypeScript with strict mode template semantics. In support of the new syntax, adopt new custom JavaScript and TypeScript files with the extensions .gjs and .gts respectively. First-class component templates address a number of pain points in today’s component authoring world, and provide a number of new capabilities to Ember and Glimmer users: accessing local JavaScript values with no ceremony and no backing class, enabling much easier use of existing JavaScript ecosystem tools, including especially styling...

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

Evolving Ember's Major Version Process Summary Introduce a standard release train for major releases, analogous to Ember's release train for minor releases: After every M.12 minor release, Ember will ship a new major, (M+1).0, which removes any deprecated code targeted for that major release. Deprecations targeting the next major cannot be introduced later than the M.10 release. The result is a steady 18-month cadence between Ember major releases, complementing our steady 6-week cadence between Ember minor releases. How this would work in practice for Ember's lifecycle from 4.8 to 7....

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

JS Representation of Template Tag Summary Formalize a Javascript-spec-compliant representation of template tag. Motivation The goal of this RFC is to improve the plain-Javascript representation of the Template Tag (aka "first-class component templates") feature in order to: reduce the number and complexity of API calls required to represent a component efficiently coordinate between different layers of build-time and static-analysis tooling that need to use preprocessing to understand our GJS syntax extensions. avoid exposing a "bare template" as a user-visible value provide a declarative way to opt-in to run-time (as opposed to...

Deprecate `import Ember from 'ember'; Summary This RFC proprosing deprecating all APIs that have module-based replacements, as described in RFC #176 as well as other Ember.* apis that are no longer needed. Motivation The import Ember from 'ember'; set of APIs is implementn as a barrel file, and properly optimizing barrel files is a lot of work, requiring integration with build time tools. If anyone one dependency in an app's dependency tree does import ... from 'ember', every feature of the framework is shipped to your users, without any ability for you to optimize. By removing this set of...

Move the deprecation workflow library to be installed in apps by default Summary Historically, folks have benefitted from ember-cli-deprecation-workflow. This behavior is so useful, that it should be built in to folks applications by default. Motivation Everyone needs a deprecation-workflow, and yet ember-cli-deprecation-workflow is not part of the default blueprint. This RFC proposes how we can ship deprecation workflow handling behavior in apps by default, which may give us a blessed path for better integrating with build time deprecations as well (though that is not the focus of this RFC). Detailed design Have...

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

Use Template Tag in Routes Summary Allow app/templates/*.hbs to convert to app/templates/*.gjs. Motivation We are rapidly approaching the point where Template Tag is the recommended way to author components. This means using .gjs (or .gts) files that combine your template and Javascript into one file. But you cannot currently use Template Tag to author the top-level templates invoked by the router (app/templates/*.hbs). This inconsistency is especially apparent when working on teaching materials for new users. Making people learn both .hbs with global component resolution and .gjs with strict template resolution before they can...

Deprecate and Remove ember-fetch Summary This RFC proposes removing ember-fetch from the blueprint for new projects, and recommends alternative, more native, ways of having "managed fetch". Motivation The package, ember-fetch, does a fair bit of deceptive and incorrect behavior that is incompatible with modern JavaScript tooling, such as being ember-fetch, yet only importing from fetch. Transition Path Remove ember-fetch from all blueprints Deprecate the npm package and archive the github repo. Migrate to an alternative for "managed fetch" What does ember-fetch do? Primarily, it wraps the native fetch in waitForPromise from @ember/test-waiters...