Ember.js 2.1 Beta Released

– By Matthew Beale

Ember.js 2.1 beta is released today. As a minor release, Ember 2.1 will be backwards compatible with Ember 2.0. Any changes to the API will be additive. This continues Ember's commitment to Semantic Versioning we began with the 1.0 release.

In addition it means many of the first features for Ember 2.2, most notably angle bracket components, have landed in Canary behind a feature flag. If you're interested in help us progress with those features, now is a good time to try them out.

On to the changes coming in our late September/early October release.

New Features in Ember.js 2.1

Ember.js 2.1 will be a minor release of Ember. This means changes to the API are made in an additive, backwards compatible manner. In roughly six weeks, these features will be part of the 2.1 stable version.

A summary of the new features in today's release follows.

{{get}} Helper

The {{get}} helper allows dynamic property lookup on objects in templates. For example, these two usages are equivalent:

{{user.name}}
{{get user "name"}}

A property with a value of a string can be passed as the second argument, making both the object and the property being read dynamic. For example:

{{get user somePropertyName}}

For more information on the {{get}} helper, reference the implementation in PR #11196 and PR #11691.

Big thanks to @jmurphyau for the implementation of this feature, and for his excellent ember-get-helper addon that demonstrated how useful this helper would be. Trying his ember-truth-helpers addon is highly recommended.

{{each-in}} Helper

The {{each-in}} helper iterates keys and values of an object. It is similar conceptually to the for (key in object) { syntax of JavaScript. For example, this code would display a list of all property names and values on the user object:

<ul>
{{#each-in user as |key value|}}
  <li>{{key}}: {{value}}</li>
{{/each-in}}
</ul>

When using {{each-in}}, the iterated list of keys will be unbound. If a new property is set on user with user.newProp = 'newVal';, the new property will not appear.

For more information on the {{each-in}} helper, reference PR #11171.

Thanks to @tomdale for the implementation of this feature, and thanks to @miguelcamba for his followup PRs.

Deprecate and Warn Handlers

In the run up to Ember 2.0, it became clear that the tooling for management of deprecations was poor. One of the reasons for this was the lack of a public, documented API for deciding how a deprecations and warnings should be handled. 2.1 introduces a proper API for our tooling to build upon.

The default behavior of a deprecation or warning is to log to the console. To change this behavior, register a handler and write custom logic. For example this handler would throw an exception for any deprecation messages with the word should in them:

Ember.Debug.registerDeprecationHandler((message, options, next) => {
  if (message.indexOf('should') !== -1) {
    throw new Error('Deprecation message with should: '+message);
  } else {
    // defer to whatever handler was registered before this one
    next(message, options);
  }
});

In this example, all warnings are silenced:

// next is not called, so no warnings get the default behavior
Ember.Debug.registerWarnHandler(() => {});

Handlers are provided with the following data through arguments:

  • message is the text logged by default
  • next is a caller for the previously registered handler. Often, this is the default handler.
  • options.id is an id in the format package-name.specific-deprecation

Deprecation handlers will also be provided:

  • options.until is the version of Ember this feature and deprecation will be removed in

As of Ember 2.0, deprecate and warn calls must provide an id option, and deprecate calls must additionally provide an until option. Addons not providing this data during 2.x will trigger a deprecation warning.

For more information see RFC #65 and the implementation in PR #11833. This API can be used with older versions of Ember via the ember-debug-handlers-polyfill, though id and until data is not provided until Ember 2.0.

Thanks to @rwjblue for shipping this API and the polyfill addon, and to @mixonic for the RFC.

Registry and Container Reform

The Ember.js registry and container are some of the most extensively used private APIs in the framework. They provided one of the only ways to lookup arbitrary objects from Ember's dependency container.

In 2.x, we are committed to stabilizing this part of the framework and offering public APIs. This first step creates a normalized way to interact with register and lookup that we expect to last through the 2.x cycle and beyond.

Ember.Application instances are passed as the first argument to initializer hooks in 2.1. initializer hooks are where dependencies between object types can be configured, and factories can be registered. Several public APIs will exist on Ember.Application instances, some of them new:

  • register - register a factory
  • inject - inject a factory into another factory, or all factories of a type
  • unregister - remove a factory from registration
  • resolveRegistration - fetch a registed factory
  • hasRegistration - check for a registered factory
  • registerOption, registeredOption, registerOptions, registeredOptions, registerOptionsForType, registeredOptionsForType which manage options for a factory (is it a singleton, can it be instantiated).

Ember.ApplicationInstance instances are passed as the first argument to instanceInitializer hooks in 2.1. instanceInitializer hooks are where objects and classes can be fetched out of the configured and booted application. Two new relevent public APIs will exist on Ember.ApplicationInstances:

  • lookup - fetch an instance of a factory (with dependencies)

For more information about these changes read RFC #46 and the initial implementation in PR #11440. To better understand dependency management in Ember and how to use these APIs, see the section on dependency management in the 1.13 guides.

This feature also introduces two minor deprecations:

  • Calling appInstance.container.lookup on the first argument to an instance initializer is deprecated in favor of appInstance.lookup.
  • Expecting two arguments for an initializer hook is deprecated

Deprecations flag where we expect to change an API in the future. It is not recommended that you use deprecated functionality, but you can also safely silence a deprecation message and continue to use that functionality until its removal date.

Huge thanks to @dgeb for his tireless work on the RFC and implementation for this work, as well as his patience building consensus around changes to Ember's internals.

For more details on changes landing in 2.1, review the Ember.js 2.1.0-beta.1 CHANGELOG.