Ember.js 2.3, a minor version release of Ember with backwards compatible
changes, is released today.
Ember.js 2.4 beta, the branch of Ember that will be released as stable in
roughly six weeks, is also being released today.
Changes in Ember.js 2.3
Ember.js 2.3 introduces a number of features we're excited to see in a stable
release.
ember-qunit 0.4.16+ is required for your codebase's test suite to be
compatible with Ember 2.3. See "Introducing Owners and Deprecating Containers"
below for more detail.
visit API
Ember FastBoot and new testing
APIs motivated the addition of a visit method for Ember.Application and
Ember.ApplicationInstance objects. Called on Ember.Application this
method accepts several configuration options.
For example, you might use this API to manually boot an Ember application
and then instruct it to visit a URL:
import MyApp from 'my-app';

$(function() {
let App = MyApp.create({ autoboot: false });
let options = {
// Prevent this application from updating the URL in the address bar
location: 'none',
// Override the default `rootElement` to render into a specific `div`
// on the page
rootElement: '#demo'
};
App.visit('/demo', options).then((/* appInstance */) => {
$('#loading').fadeOut(); // Or any other logic after rendering
});
});

Importantly, the addition of this API means FastBoot
is now usable with Ember.js 2.3 stable. FastBoot itself remains experimental,
however this is the first time you can use it with a release build of Ember.js.
The README.md for ember-cli-fastboot
is the best place to start if you want to try FastBoot.
You can read more about the visit API and its use cases in the
visit API documentation.
Reviewing the main implementation PR at emberjs/emberjs #12394 and the integration into FastBoot at
tildeio/ember-cli-fastboot #71
may also be helpful.
Many thanks to @tomdale and
@chancancode for their work implementing
this API and for their continued work on FastBoot.
Hash Helper
The (hash helper creates an object from arguments passed to it during
invocation, and then returns that object. For example this usage would create an object with
the property name:
{{#with (hash name='Bob') as |person|}}
Hello, my name is {{person.name}}
{{/with}}

This helper is introduced to make the new contextual components feature
more convenient, and it will often be used with the {{yield helper. For
example:
{{!-- app/templates/components/nice-person.hbs --}}
{{yield (hash name='Bob')}}

{{!-- app/templates/index.hbs --}}
{{#nice-person as |person|}}
Hello, my name is {{person.name}}
{{/nice-person}}

See the hash API documentation for
for details on this helper, and read the contextual components section below
for further context.
Thanks to @Serabe for his implementation of this
feature and to @MiguelCamba for his fantastic
ember-hash-helper-polyfill
addon. Using the polyfill you can start using (hash with Ember.js 1.13 or
later.
Contextual Components
The new contextual components feature allows for multiple components to
privately share data, but be invoked in a flexible manner. For example,
this {{alert-box}} component yields a contextual component composed
of the alert-box-button component and the attribute onclick:
{{!-- app/templates/components/alert-box.hbs --}}

{{yield (hash
close-button=(component 'alert-box-button' onclick=(action 'close'))
)}}

{{!-- app/templates/index.hbs --}}
{{#alert-box as |box|}}
Danger, Will Robinson!

{{#box.close-button}}
It's just a plain old meteorite.
{{/box.close-button}}

{{/alert-box}}

Contextual components are created using the nested form of the
component helper, and may be passed attrs and positional params. Contextual
components must be invoked with a . in their path, unless they are being
passed to the invoking {{component helper.
This new feature is a powerful tool for addon authors, allowing them to
yield components without having arguments to those components become de-facto
public API. In addition, when the local lookup feature of Ember's pods
architecture arrives the combination of these features will permit
completely private components to be yielded.
For more information about contextual components see the component helper
API documentation.
Further details about the API design decisions can be found in
RFC #64.
Thanks again to @Serabe for his implementation
of this feature as well as @mixonic and
@_mmun for their efforts on the RFC and design.
Introducing Owners and Deprecating Containers
Ember's container API is one of the more commonly used private APIs still
exposed. In Ember.js 2.1, a major refactor of application
boot removed access to the container from initializers and instance initializers,
creating public API alternatives.
In Ember 2.3, accessing the container property on a framework-generated
object is deprecated in favor of a public owner API.
For example, this component will dynamically lookup an audio service based
on the audioType of its model:
import Ember from 'ember';
const {
Component,
computed,
getOwner
} = Ember;

// Usage:
//
// {{play-audio model=audioModel}}
//
export default Component.extend({
audioService: computed('model.audioType', function() {
let owner = getOwner(this);
let serviceName = this.get('model.audioType');
return owner.lookup(`service:audio-${serviceName}`);
}),
click() {
let player = this.get('audioService');
player.play(this.get('model.file'));
}
});

The return value of getOwner will be an Ember.ApplicationInstance
for objects generated by the framework.
ember-qunit 0.4.16+ includes important compatability patches for Ember
2.3. Please upgrade ember-qunit to ensure your test suite continues to work
properly and without deprecation warnings. Specifically 0.4.16+ includes
PR #119 to ember-test-helpers
adding getOwner compatibilty.
For more information about migrating code from using container to getOwner,
see the deprecation guide.
Further details about the API design decisions can be found in
emberjs/emberjs #11874
and emberjs/emberjs #12555.
The ember-getowner-polyfill addon
provides compatibility for getOwner back to Ember.js 1.10.
Many thanks to @dgeb for his tireless efforts
implementing this feature, and for his time buildling consensus around
improvements to the Ember dependency injection API. Additionally credit is
due to @rwjblue for his polyfill and upgrade PRs to
Ember Data, Liquid-Fire, and Ember-i18n.
These provide a good example of how to upgrade any addon or app codebase.
Removing the jQuery version assertion
Ember has long had an assertion that ensured only supported versions of jQuery
were present. With the introduction of Ember-CLI and ability to use package
managers for client-side code, this assertion is redundant.
Recent releases of jQuery have triggered the outdated assertion. Since it is
not really required any longer, we've removed it.
Ember remains compatible with jQuery 1.7+.
Ember.js 2.3.0+, 2.2.2, and 1.13.12 have this assertion removed.
For more details on changes landing in 2.3, review the
Ember.js 2.3.0 CHANGELOG.
Ember.js 2.4 beta
No new features are slated for Ember 2.4. During the canary cycle leading to
this beta, the core team and community have been primarily focused on
performance improvements or feature work still behind a feature flag.
For more details on changes landing in 2.4, review the
Ember.js 2.4.0-beta.1 CHANGELOG.