Released

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...