Ember.js 2.1 Beta released

The Ember.js 2.1 beta version was released today. As a minor version, Ember 2.1 will be backward compatible with Ember 2.0. Any changes to the API will be additional.This continues Ember’s promise Semantic version control
We start with version 1.0.

In addition, this means that many of the first features of Ember 2.2, especially the angle bracket components, have already landed in Canary behind the feature logo. If you are interested in helping us improve these features, now is a good time to try them.

Regarding the changes we released in late September/early October.

New features in Ember.js 2.1

Ember.js 2.1 will be a minor version of Ember. This means that changes to the API are made in an additional, backward compatible way. In about six weeks, these features will become part of the 2.1 stable release.

A summary of the new features released today is as follows.

{{get}} helper

This {{get}} The helper allows dynamic attribute lookup of objects in the template. For example, these two usages are equivalent:

{{get user "name"}}

Attributes with string values ​​can be passed as the second parameter, so that both objects and attributes are dynamically read. E.g:

{{get user somePropertyName}}

For more information {{get}} Helper, reference implementation PR #11196 with
PR #11691.

thank you very much @jmurphyau To achieve this feature, and his excellent
ember-get-helper The plug-in demonstrates the usefulness of this assistant.Try his
Embers truth helper The plugin is highly recommended.

{{each-in}} helper

This {{each-in}} The helper iterates over the keys and values ​​of the object.It is similar in concept to for (key in object) { The syntax of JavaScript.For example, this code will display a list of all attribute names and values user

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

when using it {{each-in}}, The iterative list of keys will be unbound.If a new attribute is set user with user.newProp = 'newVal';, The new attributes will not appear.

For more information {{each-in}} Helper, reference
PR #11171.

Thank you @tomdale For achieving this feature, and thanks
@miguelcamba For his follow-up PR.

Deprecation and warning handlers

Before Ember 2.0, it was clear that the tools used to manage deprecation were poor. One of the reasons for this is the lack of public and documented APIs to determine how to deal with deprecations and warnings. 2.1 A suitable API is introduced for our tool to build.

The default behavior for deprecation or warning is to log in to the console. To change this behavior, register the handler and write custom logic.For example, this handler will throw an exception for any deprecated messages with words
should among 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 muted:

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

The handler provides the following data through parameters:

Deprecation handlers will also be provided:

Starting from Ember 2.0, deprecate with warn Call must provide id Options, and deprecate The call must be provided separately until Options. Plugins that did not provide this data during 2.x will trigger a deprecation warning.

For more information, see RFC #65
And implement PR #11833. This API can be used with older versions of Ember
Embers debug handler polyfill, in spite of id with until The data was not available until Ember 2.0.

Thank you @rwjblue Used to publish this API and polyfill plug-ins, and @mixonic
For RFC.

Registration and container reform

The Ember.js registry and container are one of the most widely used private APIs in the framework. They provide one of the only ways to find any object in Ember’s dependency container.

In 2.x, we are committed to stabilizing this part of the framework and providing public API.This first step creates a standardized way of interaction register with lookup We hope to continue into the 2.x cycle and beyond.

Ember.Application The instance is passed as the first parameter to initializer
The hook in 2.1. initializer Hooks are places where you can configure dependencies between object types and you can register factories.Several public APIs will exist in Ember.Application Examples, some of which are new:

  • register -Registered factory
  • inject -Inject one factory into another factory, or all factories of one type
  • unregister -Remove factory from registration
  • resolveRegistration -Get registered factory
  • hasRegistration -Check the registered factory
  • registerOption, registeredOption, registerOptions, registeredOptions,
    registerOptionsForType, registeredOptionsForType It manages the options of the factory (it is a singleton and can be instantiated).

Ember.ApplicationInstance The instance is passed as the first parameter to
instanceInitializer The hook in 2.1. instanceInitializer Hooks are places where objects and classes can be extracted from the configured and launched application.Two new related public APIs will exist in Ember.ApplicationInstances:

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

For more information about these changes, please read
RFC #46
And the initial implementation
PR #11440. To better understand dependency management in Ember and how to use these APIs, please refer to the Dependency management In the 1.13 guide.

This feature also introduces two small deprecations:

  • Make a call appInstance.container.lookup It is not recommended to use the first parameter of the instance initializer appInstance.lookup.
  • It is not recommended to use the two parameters of the initializer hook

We hope to change the API in the future. It is not recommended that you use the deprecated feature, but you can safely mute the deprecation message and continue to use the feature until its removal date.

thank you very much @dgeb Thank him for his unremitting efforts to RFC and the implementation of this work, as well as his patiently building consensus around the changes in Ember’s internal structure.

For more detailed information about the changes to Login 2.1, please check
Ember.js 2.1.0-beta.1 change log.

Leave a Reply

Your email address will not be published. Required fields are marked *