Ember.js 1.10.0 and 1.11 Beta released


We are happy to announce the release of the first beta version in the Ember.js 1.10.0 and 1.11 series. This is the tenth cycle of the release process that we started after the 1.0 release.

Version 1.10 represents the efforts of at least 50 contributors in more than 553 commits.

HTMLBars template engine

Throughout 2014, the Ember.js community has devoted joint efforts to develop new template solutions. This new library called HTMLBars prevents Handlebars (the previous library) from supporting available features and performance improvements. We are happy to announce the inclusion of the HTMLBars template engine in Ember.js 1.10.

HTMLBars will enable the implementation of several APIs described in
The road to Ember 2.0, And help us continue to improve rendering performance. In addition, it will allow us to continue to support all Ember 1.x template syntax.

Without the continuous contributions of the Ember community and core team, this long-term effort will not succeed.No special order, apologies to anyone we missed, we want to thank
@Chrisdon, @wycats,
@_mmun, @书呆子20,
@mixonic, @ebryn,
@salzhrani, @rwjblue,
@tomdale, A person,
@kpdecker And many alpha and beta testers who provide feedback and bug reports. You are a “stable but not stagnant” thing.

New features in Ember.js 1.10

HTMLBars 0.8.5

Ember.js 1.10 depends on HTMLBars 0.8.5. In order to mitigate this and subsequent changes in the template library version, Ember’s template compiler will be packaged as part of the release file. For example, JSBin in Ember 1.9 needs to be updated from:

<script src="http://builds.handlebarsjs.com.s3.amazonaws.com/handlebars-v2.0.0.js"></script>
<script src="http://builds.emberjs.com/tags/v1.9.1/ember.js"></script>

to

<script src="http://builds.emberjs.com/tags/v1.10.0/ember-template-compiler.js"></script>
<script src="http://builds.emberjs.com/tags/v1.10.0/ember.debug.js"></script>

This ember-template-compiler.js Only needed for template compilation. The runtime dependencies of HTMLBar are built into the framework file.

In order to smoothly upgrade to 1.10 and HTMLBars, Ember-CLI users should update to 0.1.12 or later, delete the Handlebars dependency of their application, and modify the Brocfile to not load Handlebars.
This difference
Shows the changes required to upgrade the Ember-CLI application to 1.10.

Ember App-Kit users should upgrade to Ember-CLI.

Ember-Rails users should upgrade to version 0.16.1 and then remove their Handlebars dependency.

Application developers who follow a non-standard build pipeline should check the instructions Robert Jackson published this week
And join the conversation emberjs.com
Or on IRC.

Performance improvement

Ember.js 1.8 introduced a performance regression, which we expect to reappear in version 1.10. In December, the team was Discourse created
Human performance Repurchase. This project helps Ember developers analyze and measure the performance of the framework.

Using these benchmarks, we are happy to report a 12% improvement in performance in common rendering scenarios between 1.7 and 1.10, and a 50% improvement between 1.9 and 1.10.

Better rendering and general framework performance are still priorities for the core team and the community. Specific goals include reactive rendering of HTMLBar, a more optimized metal view, limited observation, and improvements to the Ember object model.

Chain other blocks

HTMLBars are built using the Handlebars parser, and will continue to gain functionality related to template syntax. Ember 1.10 supports chained else assistants, the most common use is else if. one example:

{{#if isAtWork}}
  Ship that code!
{{else if isReading}}
  You can finish War and Peace eventually...
{{/if}}

Chained else assistant and any else, Including those with with each
helper.

You can read more about the implementation In the Handlebars warehouseThank you @kpdecker For this improvement.

Block parameters

Ember 1.10 introduced block parameters. Block parameters provide a consistent range for the template and allow components to pass internal values ​​to downstream ranges.

E.g:

{{currentUser.name}} {{! available on the controller }}
{{#each cars as |car|}}
  {{#with car.manufacturer as |make|}}
    {{make.name}}
    {{currentUser.name}} {{! still the controller scope }}
  {{/with}}
{{/each}}

Preserving the template context makes the template easier to read, and passing variables to sub-scopes allows a new mode of component composition.

Block parameters are passed from the template yield helper.For example, this component produces fullName with age Values:

// app/components/x-customer.js
export default Ember.Component.extend({
  fullName: function(){
    var customer = this.get('customer');
    return [customer.get('firstName'), customer.get('lastName')].join(' ');
  }.property('customer.firstName', 'customer.lastName'),

  age: function(){
    return (new Date() - this.get('birthday')) / (86400000 * 365);
  }.property('birthday')
});
{{!-- app/components/x-customer.hbs --}}
<div class="customer">
  {{yield fullName age}}
</div>
{{!-- app/templates/index.hbs --}}
<div class="layout">
  {{#x-customer customer=model birthday=model.birthday as |fullName age|}}
    Hello, {{fullName}}. You are {{age}} years old.
  {{/x-customer}}
</div>

thank you very much @_mmun Used to implement this new feature.

Inject properties

Ember 1.x exposes two APIs for managing dependency injection.The first is the application initializer API, using register with inject The method on the application instance.The second one allows injection by configuring on the controller needs. You can read more about these modes
Dependency injection guide.

The newly injected properties provide a more declarative API for dependency injection.

use Ember.inject.service() Inject a service with the same name as the injected property. In this example, storage Service is injected into
storage property:

export default Ember.Component.extend({
  storage: Ember.inject.service()
});

Pass the name to service() Methods allow different services to be injected. E.g:

export default Ember.Component.extend({
  storage: Ember.inject.service('local-storage')
});

In addition to injecting services, the controller can also inject Ember.inject.controller.

It is important that these injections are inert.When used in a unit test, the stub service can be used in create. E.g:

test("a value is saved on storage", function(){
  expect(1);
  var component = this.subject({
    storage: {
      write: function(){
        ok(true, 'value was written');
      }
    }
  });

  var element = this.append();
  element.click();
});

reference API documentation Learn more about this new feature.

Thank you Slindberg Because he realized this function.

Notable deprecation

With the development of Ember.js, various APIs have been deprecated to allow them to be removed in future major versions (such as 2.0).This
Deprecated pages Summarizes the deprecation situation and demonstrates how to update to the new API.

  • clearly {{bind}} The assistant has been deprecated. This assistant has long been marked as private and is a legacy Sproutcore feature. This assistant will be removed in Ember 1.11.
  • It is not recommended to use unquoted socket names in 1.10.An example of this is
    {{outlet modal}}Should be rewritten as {{outlet "modal"}}This ensures that the outlet helper is consistent with others, where unquoted words are values ​​rather than string literals.
  • This beforeObserver The feature was deprecated in Ember 1.10. Observers were rarely used before, but they usually cause significant overhead to the observer system. For observers who need to know the previous value of the attribute, it is easier and more effective to implement caching.Read more about how to do this Deprecated pages.
  • Observed childViews An array ContainerView Deprecated.
  • Set up childViews The attributes on the view definition are deprecated in 1.10. E.g:
var ChildB = Ember.View.extend();

export default Ember.ContainerView.extend({
  childViews: [ 'childA', ChildB ],
  childA: Ember.View.extend()
});

This use childViews It is inconsistent with other uses of the entire Ember, so it is difficult to achieve with good performance. It is preferred to explicitly create the view during initialization:

var ChildB = Ember.View.extend();

export default Ember.ContainerView.extend({
  init: function(){
    this._super();
    this.pushObject(this.createChildView(this.childA));
    this.pushObject(this.createChildView(ChildB));
  },
  childA: Ember.View.extend()
});

New features in Ember.js 1.11 beta

Ember.js 1.11 beta continues to release a series of versions and iterates the framework towards our 2.0 goal. After six weeks, these features and some other features will be declared stable.

Inline if

In 1.11 Ember if The helper can be used inline:

{{if isEnabled 'active' 'disabled'}}

Thank you @marciojunior_me Used to achieve this function.

Each has an index

This each Helper will support one index Block parameters in Ember 1.11:

{{#each people as |person index|}}
  {{! The first index value will be 0 }}
  <div>{{index}}: {{person.name}}</div>
{{/each}}

Thank you @_mmun Used to achieve this function.

Binding attribute syntax

Familiar with current Ember developers bind-attr Syntax, used to declare attribute bindings on HTML elements. The original motivation of HTMLBars was to improve this syntax.

Ember 1.11 introduces a more intuitive API for property binding.For example, here color The variable is bound to the class of the div:

<div class="{{color}}"></div>

The inline if helper can also be used in these contexts:

<div class="{{color}} {{if isEnabled 'active' 'disabled'}}"></div>

For some attributes, such as disabled Boolean value, it is advisable to pass literal value. one example:

<input disabled={{isDisabled}}>

To allow binding non-string value data to boolean attributes and custom element attributes, bind attributes use
Property first Setter.

When binding to an attribute, Ember first checks whether the attribute is an attribute of the element’s DOM node (using uppercase normalization). If it is, use the property to set the value. E.g:

<input disabled={{isDisabled}}>
// disabled is a property of input elements, so...
input.disabled = true;

If the attribute does not exist as an attribute, set its value as an attribute:

<div class={{color}}>
// class is not a property of div elements, do...
div.setAttribute('class', 'red');

For SVG attributes and style attributes, we have made exceptions to this mode. Despite these exceptions, the attribute first rule is a good way to describe what is happening behind the scenes. In practice, the binding syntax feels natural.

thank you very much @mixonic, @_mmun, with @wycats Thank them for their efforts in designing and implementing this feature.

Named substate

Ember routing has two routing sub-states.This loading If the asynchronous hook of the route is still being processed, it will enter the sub-state, and error When the asynchronous hook promise is rejected, it will enter the sub-state.

The sub-state is a sibling route. when. . .when new route cars.new loading, cars.loading
Enter the sub-state.This application The route does not have a parent namespace to nest its sibling nodes.This makes the use of loading with error Impossible sub-states of the application path.

Naming sub-states adds a new search method to sub-states. The name of the route is pre-added to the sub-state.So a valid loading sub-state application Can be defined as
application_loading.

Thank you @machty Used to log in to this function.

Component assistant

Ember components can pass component helper. For example, this logic in the template:

{{#if isRed}}
  {{x-red}}
{{/if}}
{{if isBlue}}
  {{x-blue}}
{{/if}}
{{if isGreen}}
  {{x-green}}
{{/if}}

Can now be calculated by attributes and component helper.

{{component colorComponentName}}

The property colorComponentName Should have a value x-red, x-blue and many more. As the value of the property changes, the rendered components will also change.

thank you very much @卢克梅利亚 Used to publish this new feature.

Significant deprecation in 1.11

The following deprecation plan is released with Ember.js 1.11:

  • This ObjectController Will be removed in Ember 2.0.In Ember 1.11, both are explicitly used ObjectController And use the generated proxy behavior ObjectController Will raise a deprecation warning.

As the features included in Ember 1.12 are developed, additional deprecations may be added in version 1.11.

Change log

Use Ember?Please take 10 minutes to participate in the discussion and share your feedback 2015 Ember Community Survey. Open until February 20th.



Leave a Reply

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