Ember Blog

Ember.js 2.8-LTS, 2.9 and 2.10 Beta Released

2016-10-17T00:00:00+00:00

Today, we are releasing Ember 2.8-LTS (a long-term support release), Ember 2.9.0 and Ember 2.10 beta.

Ember.js 2.8-LTS

Ember 2.8-LTS is our second long-term support release. You can install it by running bower install --save ember#lts-2-8 in your projects.

The LTS channel is designed for Ember users who would like to upgrade less frequently, while still getting support from the project and the wider ecosystem. At the same time, it allows addon authors to know which versions of Ember to focus their effort on.

Per our usual policy, Ember 2.8-LTS is released six weeks after the 2.8.0 stable release. This allows ample time to fix any reported regressions and ensures a rock solid LTS release. It will continue to receive critical bugfixes for six release cycles (roughly June 2017), and security patches for ten release cycles (roughly February 2018).

Meanwhile, Ember 2.4-LTS will continue to receive critical bugfixes for another two release cycles (roughly January 2017), and security patches for six release cycles (roughly June 2017). Users of Ember 2.4-LTS should make use of this overlapping period to transition over to Ember 2.8-LTS.

Most notably, as we have mentioned in the Ember 2.4-LTS announcement, applications who are using the legacy views and controllers addons will need to migrate away from these addons before they can upgrade.

For more details on the changes landing in Ember.js 2.8-LTS, please review the Ember.js 2.8.2 CHANGELOG.

Ember.js 2.9

In the Ember 2.9 beta blog post, we announced our intention to include the new Glimmer 2 rendering engine in the 2.9 release. However, after careful consideration, we have decided to temporarily hold off on the integration.

This means that 2.9 will ship with the same rendering engine as 2.8 and does not include any new features, notable changes or deprecations.

When we moved ahead with Glimmer in the 2.9 beta channel in September, all of Ember's tests were passing, we had no known blockers and it was already working fine for a number of apps we tested (including some core team member's production apps). Due to the magnitude of the internal changes, we fully expected to find bugs not already covered by our initial testing, so we called for the community to beta test the release.

We got a lot of positive results during the beta period, and some of our community sites (such as Ember Observer and Ember Addons) have already migrated to using the beta in production. However, as more apps tested the beta, we began to see a few critical edge cases reported during the mid-to-late part of the beta cycle. We were able to fix a number of them, but at this point, there are still a handful of open issues.

As we said in the Ember 2.9 beta announcement, the "primary goal of this release is maximal compatibility – we expect the final release to be a drop-in, completely backwards compatible upgrade for virtually all Ember users". Therefore, we decided to err on the side of caution and take another six weeks to ensure the smoothest possible experience for our users.

While it is quite rare for a feature to be backed out from the beta channel, we consider the ability to do so a strength of our release process, and we would like to thank everyone who took the time to test their application against the beta channel.

For more details on the changes landing in Ember.js 2.9, please review the Ember.js 2.9.0 CHANGELOG.

Ember.js 2.10 beta

As mentioned above, we will continue the Glimmer 2 integration work in Ember 2.10 beta, with a focus on resolving the remaining compatibility issues. You can read about the integration in the original announcement.

If you haven't already, we highly encourage you to test your application against 2.10 beta as soon as possible and report any issues you encounter. Given that it already went through a complete beta cycle and we were quite close to releasing it, we expect this to go smoothly for most apps.

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

Ember.js 2.8 and 2.9 Beta Released

2016-09-08T00:00:00+00:00

Today, the Ember core team is happy to announce two new Ember.js releases – Ember.js 2.8 and Ember.js 2.9 beta.

Ember.js 2.8

Ember.js 2.8 is a minor release with only backwards compatible changes.

LTS Candidate

The Ember.js 2.8 release is considered a release candidate for the LTS (long-term support) channel. As described in the original LTS announcement, the 2.8 branch will be moved into the LTS channel six weeks after today's release. Although we don't anticipate any issues, this process ensures the LTS releases will be rock solid.

Engines

Ember.js 2.8 introduced a new Engines API, which allows multiple logical applications to be composed together into a single application from the user's perspective.

The best way to use this feature in your apps is through the ember-engines addon. To get started, check out the excellent guides written by @trentmwillis.

This release introduced a set of low-level APIs for the core functionality along with the usual semver guarantees. While the ember-engines addon itself remains experimental, the introduction of these public APIs means that ember-engines is now usable with Ember.js 2.8 without feature flags.

Work on engines has proceeded over the past year in both Ember core as well as the addon. Ember's architecture has been enhanced to provide the base classes and hooks needed to support engines. The addon then makes use of these interfaces to provide a smooth experience building and consuming engines.

Until now, none of the engine-related classes and hooks in Ember have been exposed publicly. However, starting with Ember.js 2.8, the following APIs are now public:

Ember.Engine class - The base class for Ember.Application. Its only public interface is related to initializers and instance initializers, which is then inherited by applications.
Ember.EngineInstance class - The base class for Ember.ApplicationInstance.
{{mount}} helper - Allows for the mounting of routeless engines in templates. This helper currently only takes one argument, the name of the engine, e.g. {{mount "chat-engine"}}.
mount router DSL - Allows routable engines to be mounted at a location in a route map.

By making these APIs public, ember-engines and other addons will be able to access them without a feature-flag. By accessing only public interfaces in Ember, an addon won't need to rely on private overrides and can provide as stable an experience as possible.

We predict that engines will grow in popularity once work on lazy loading is complete. By delaying the loading of engines until they're accessed, we can decrease the initial payload size and startup time for applications. If you're interested in helping to implement or test lazy loading of engines, please check out the thorough attack plan written up by @nathanhammond.

Other Notable Features

`Enumerable#includes` and `Array#includes`

In an effort to remain in line with ES standards, the methods Enumerable#contains and Array#contains have been deprecated in favor of the new methods Enumerable#includes and Array#includes.

Addon authors should use ember-runtime-enumerable-includes-polyfill to fix the deprecation in a backwards-compatible way.

Thanks to @alexspeller for the RFC that proposed this change.

Thanks as well to @bmeurant for the PR that implemented the change.

`Ember.String.isHTMLSafe`

The new method Ember.String.isHTMLSafe detects if a string was decorated using Ember.String.htmlSafe.

For example:

  
  var plainString = 'plain string',
    safeString = Ember.String.htmlSafe('<div>someValue</div>');

Ember.String.isHTMLSafe(plainString); // false
Ember.String.isHTMLSafe(safeString);  // true

Thanks to @workmanw for the RFC that proposed this new API, as well as the PR that implemented it.

On a related note, please create safe strings with Ember.String.htmlSafe instead of the using the deprecated Ember.Handlebars.SafeString. See the deprecation guide for details.

`Ember.Test.checkWaiters`

The new method Ember.Test.checkWaiters provides a simple mechanism for test tooling to determine whether all async test waiters have settled. This replaces the intimate API Ember.Test.waiters, which has been removed in Ember.js 2.8.

Thanks to @rwjblue and @krisselden for implementing this method.

For more details on the changes landing in Ember.js 2.8, review the Ember.js 2.8.0 CHANGELOG.

Ember.js 2.9 beta

Ember.js 2.9 beta is also being released today. Per our usual release cadence, it will be released to the stable channel in six weeks.

This release will not introduce any new features or deprecations. Instead, this release will be focused around integrating the Glimmer 2 rendering engine into Ember.

Glimmer 2

In this year's EmberConf keynote, Yehuda mentioned that we are working on a highly optimized rendering engine for Ember called Glimmer 2. A few weeks ago, we announced the Glimmer 2 alpha to invite our community to help test the new engine. Today, we are very excited to announce that the Glimmer 2 engine will be included in the 2.9 beta release.

Compatibility First

As mentioned above, the initial Glimmer 2 integration does not expose any new user-facing features. The primary goal of this release is maximal compatibility – we expect the final release to be a drop-in, completely backwards compatible upgrade for virtually all Ember users.

During the alpha testing period, the Ember core team and our community were laser-focused and worked really hard to achieve this goal. Thanks to all the alpha testers, addon authors and contributors who reported issues or chimed in with patches, we are able to meet our compatibility target and feel confident about including Glimmer 2 with the 2.9 release.

That being said, despite our best efforts and the extensive alpha testing, we still might have gotten a few details wrong, hence the beta releases. We would really appreciate it if you could start testing your applications and report any regressions, if you have not already done so. You may refer to the master issue for a list of known issues.

It's also worth noting that the 2.8-LTS release (when available) will be the final LTS release to include the current-generation rendering engine, which will be supported with critical bugfixes until at least May 2017 and security patches until at least October 2017.

New Template Serialization Format

Glimmer 2 adopted a new serialization format for the precompiled templates. The new serialization format offers a few benefits – among them are reduced byte size (hence download time) and parse time.

Take this simple template for example:

  
  Hello {{name}}! {{#if isFriday}}Happy Friday!!!{{/if}}

In Ember.js 2.8, this template compiles into a JavaScript function with 2273 bytes, or 472 bytes minified and gzipped. At the time of writing, Ember.js 2.9 beta compiles the same template into a JSON string with 374 bytes, or 213 bytes minified and gzipped. You can explore the difference in this gist.

There are a few caveats with the previous paragraph. First of all, the details of the templates serialization is a private API that is subject to change anytime and should not be relied on. Second, the reduction varies between templates, depending on various factors such as the number of blocks used in the template. Third, minification and gzip are usually applied to the entire application bundle and they work a bit differently in those environments.

Nevertheless, these numbers offer a good ballpark estimates on what you could expect. From our experience, the reduction generally scales well and holds up in real-world scenarios.

Besides the byte size savings, the JSON serialization format also reduces parse time and allows us to defer the work till the template is actually used.

This is an area that is still being actively worked on, and we expect the serialization format to go through some more changes before the Ember.js 2.9 stable release.

Performance

One of the overarching goals of the Glimmer 2 project is to improve performance in Ember. While compatibility is the immediate priority for this release, performance remains an important secondary consideration.

Our conservative goal for this first release is to avoid introducing any accidental performance regressions. Based on our testing, we have cleared that goal with ample headroom.

As the benefits of Glimmer 2 begin to trickle in, we have already seen noticeable improvements to rendering performance (both initial render and re-rendering). Among other things, the {{link-to}} helper and {{#each}} loops with big lists appear to be significantly faster. Component instantiation has also seen some modest improvement.

However, we have also noticed a performance regression in the pre-render phase. Specifically, we have seen a small increase in the vendor.js byte size and an increased delay before the application gets to render anything. This regression eats into the rendering improvements. We are actively working on these issues and we expect them to be addressed before the final release in Ember 2.9.

Despite the caveats, our data suggest the savings from template byte size and improved rendering performance more than offset the current issues. Therefore, we expect most applications to see an overall improvement in performance upon upgrading to the beta release.

It is worth noting that these observations are recorded from complex production applications maintained by members of the core team (as opposed to isolated synthetic benchmarks). Given the current state of affairs, we are hesitant to circulate premature numbers that are specific to a handful of applications. We plan to perform some thorough analysis as we get closer to the final release.

In the meantime, we encourage you to test the beta release against your own applications. If you notice that certain common patterns have become slower, please report them as bugs. As always – when running performance benchmarks, please make sure you are using the minified production build (ember.min.js). The debug builds contain a lot of helpful development aids that impact performance negatively.

Future Work

While this release serves as an important milestone and proving ground for the Glimmer 2 project, we are barely scratching the surface here. One of the informal mandates of the Ember project is "we will keep on shipping", and this is no exception.

The Glimmer 2 engine unlocks a whole new arena of performance optimizations. Once the dust settles, we are committed to keep iterating on performance improvements. Ultimately, our goal is to make the overhead of breaking up an app into small, composable components negligible over time. We are optimistic that there will still be ample headroom for further improvements in this area.

Besides performance, Glimmer 2 has laid a solid foundation for us to build on.

The project originally started when Tom, Yehuda and I spiked on implementing "angle bracket components" in the HTMLBars ("Glimmer 1") engine over a year ago. This exercise highlighted some fundamental misalignments between the current rendering stack and the direction Ember is headed.

While HTMLBars handled basic templating, it left the implementation of many of Ember's view layer features (notably components) up to Ember itself. Not only did it make new features more difficult to implement, it made it hard to implement them efficiently out of the gate.

As Ember has moved towards components and "data-down, actions-up", we wanted to do many optimizations that just weren't a good fit for the HTMLBars architecture. The lessons we learned from the spike ultimately leading us down the journey that is now known as the Glimmer 2 architecture. The underlying technologies are very interesting, but I will save those details for another time.

As an Ember user, you can expect the new engine to unlock some long-awaited features, such as FastBoot rehydration, incremental rendering and a refreshed approach to components once the initial integration is complete.

Thank You!

Since forking HTMLBars, the Glimmer repo has clocked over 850 commits, not to mention the integration effort that happened on the Ember side and also in the wider ecosystem. All of these would not be possible without the help from our community.

Thank you to every one who helped us get here – from the companies who donated employees' time to the individual contributors who made personal sacrifices to make this happen.

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

Ember Node.js LTS Support

2016-09-07T00:00:00+00:00

Ember is committed to being a good steward of our collective codebases as part of the Node.js ecosystem. In that spirit we will be following the Node.js Long Term Support Schedule to provide clear guarantees of which versions of Node.js we support and how long we will support them. We will test against the same set of releases which the Node.js Long-term Support Working Group says they support: any "Current", "Active LTS", or "Maintenance" releases.

What does support mean?

All Ember projects can be expected to work in any of the supported Node.js versions and will support every documented feature. We will not maintain separate branches or classes of support for different Node.js support classifications. For example, Ember CLI can be expected to work just the same running on a "Maintenance" Node.js version as it does on a "Current" Node.js version. Not all of our projects presently align to this pattern but we will, over time, coalesce to this state.

Meeting this commitment does not come without cost and tough decisions. However, as maintainers of foundational libraries, we believe that it is in our best interest to validate the legitimacy of the Node.js LTS plans, help position Node.js as a reliable and dependable tool for all enterprises, and contribute toward improving the reputation of the ecosystem.

How We Drop Support

To make it easier for us to deliver on our support promise we have adopted a policy that the HEAD of our master branches will be compatible with all versions of Node.js currently receiving support. For any Ember project on the day we drop support for a Node.js version the following things will happen:

We will update the engines key inside of package.json to specify the versions supported by the project.
We will update the testing targets to remove the newly-unsupported Node.js version from the list.
We will begin accepting code without testing it against the newly-unsupported version of Node.js.

For projects with an unspecified release model we will release one last version of the project prior to those steps. The version number change will reflect SemVer with respect to the APIs of the project and not take into consideration removal of Node.js version support. This means that the release may show up as a "patch" version release. For example, if we're dropping support for Node.js 0.10 and have a project at version 1.3.3 we can drop Node.js 0.10 support when we release version 1.3.4.

For Ember CLI, which follows a six week release train model, we will continue to patch the currently released version and maintain compatibility. Those patches will not break compatibility with the Node.js versions that Ember CLI supported when it was released. The next six week release of Ember CLI will drop support for the newly-unsupported Node.js version. For example, if we release Ember CLI 2.8.0 on September 6, drop support for Node.js 0.10 on October 1, and discover a bug on October 5 necessitating a 2.8.1 patch release that release will support Node.js 0.10 even though we have officially dropped support. The first version which will not support Node.js 0.10 will be Ember CLI 2.9.0 scheduled to be released on October 17.

Node.js 0.10 & Node.js 0.12

Over the next four months Node.js will remove the 0.10 and 0.12 versions from "Maintenance." We in the Ember community will follow suit. This means that on October 1, 2016 we will drop support for Node.js 0.10 and on January 1, 2017 we will drop support for Node.js 0.12.

Both of these versions are very long in the tooth and have had a good run but we're not sad to see them go. We're looking forward to getting to use language features we've had for years in other environments.

Recommended Version

We recommend that you use the most-recent "Active LTS" version of Node.js. At present that is Node.js v4.5.0. This is not to say that you may not use other versions, but by rule the current "Active LTS" will receive the most attention during our testing cycles and be most broadly used within the community.

Future Plans

We recognize that we don't have the privilege of unilaterally setting this as the default for the entire Node.js ecosystem. It is our hope that with leadership from our community we can encourage more of the Node.js ecosystem to commit to following the schedule laid out by the Node.js LTS Working Group.

We don't presently rely upon transpilation to support older versions of the Node.js runtime from a codebase using current JavaScript features. This may change in time but we don't yet believe the story for tooling and debugging of transpiled JavaScript for Node.js has reached the inflection point where the benefits outweigh the costs.

Further, if we find ourselves maintaining our own forks or depending upon legacy versions of much of the JavaScript ecosystem, we reserve the option to change our approach in the future. As always we will be paying close attention to the community's needs and will give at least a six month notice of any change to this stated support policy.

Special thanks to Hannah Wolfe for helping direct us to this approach.

Announcing The Glimmer 2 Alpha

2016-07-29T00:00:00+00:00

In this year's EmberConf keynote, Yehuda mentioned that we are working on a highly optimized rendering engine for Ember called Glimmer 2.

On behalf of all the contributors who have lent a hand along the way, I am very excited to announce that we have just released Ember 2.9.0-alpha.1, the first official build with Glimmer 2 included.

🔑 A Key Milestone 🔑

During the alpha testing period, we will publish new alpha builds on a weekly cadence, following the beta releases schedule. The alpha releases will be cut from the master branch, but with all experimental features other than ember-glimmer stripped from the builds.

The purpose of the alpha releases is to enable our community – especially the addon and tooling ecosystem – to start testing the new engine for compatibility and offer feedback. Needless to say, the alpha releases are not intended for production use.

To test your apps with the alpha builds, simply run bower install --save ember#alpha and follow the prompt to persist the resolution.

From Ember's perspective, integrating Glimmer 2 does not expose any new user-facing features. Even though it is a complete rewrite under the hood, we expect the final release to be a drop-in, completely backwards compatible upgrade for virtually all Ember users. Notably, we will follow our usual SemVer guarantee and ensure all public APIs continue to function as advertised. At this point, we do not expect to introduce any new deprecations along with the initial release.

That being said, despite our best efforts, we might not have gotten every detail right in our very first attempt, hence the alpha releases. We would really appreciate it if you could start testing your applications and report any regressions. You may refer to the master issue for a list of known issues.

It is worth noting that the version number (2.9.0-alpha.1) does not imply the new engine will be automatically included in the 2.9 final release. Just like any other changes, the Glimmer 2 integration is subject to the usual rigor and stability requirements of our release process. The core team will make the final decision on when to promote the feature into beta and stable releases based on our learnings from the alpha period.

Based on current information, the 2.8-LTS release (when available) will likely be the final LTS release to include the current-generation rendering engine, which will be supported with critical bugfixes until at least May 2017 and security patches until at least October 2017.

🚀 A Note On Performance 🚀

While one of the overarching goals of Glimmer 2 is to improve performance, the immediate priority in the alpha phase is maximal compatibility. We are barely scratching the surface with the possible optimizations unlocked by the new engine, and once the dust settles there will be ample headroom for further improvements.

That being said, you should start seeing some improvements in rendering performance with each alpha release, as well as reduced download/parsing time thanks to the new templates serialization format.

We are also aware of a few minor bugs that cause performance problems in the first alpha release, which we plan to address quickly. However, it is also possible that we inadvertently regressed performance in certain scenarios. If you noticed certain common patterns have become slower, please report them as bugs.

As always – when running performance benchmarks, please make sure you are using the minified production build (ember.min.js). The debug builds contain a lot of helpful development aids that are known to impact performance negatively.

🎁 A Whole Lot More To Come 🎁

Besides performance, Glimmer 2 has laid a solid foundation for us to build on.

As an Ember user, you can expect the new engine to unlock some long-awaited features, such as FastBoot rehydration and a refreshed approach to components once the initial integration is complete.

❤️ A Big Thank You ❤️

Since forking HTMLBars, the Glimmer repo has received over 700 commits, not to mention the integration effort that happened on the Ember side, all of which would not be possible without the help from our community.

Thank you to every one who helped us get here – from the companies who donated employees' time to the individual contributors who made personal sacrifices to make this happen.

With all of that out of the way – happy alpha testing! 🍾🎊🎉

📚 Further Reading/Watching 📚

🔜 Stay tuned for more Inside Glimmer 2 articles from this blog
🚧 Glimmer Architecture Guides
Opening Keynote from EmberConf 2016
The Future of Ember Templating from EmberConf 2016
Inside Glimmer 2: What Is A Compiler?
Glimmer 2 Deep Dive

Ember Data 2.7 and 2.8 Beta Released

2016-07-25T00:00:00+00:00

Ember Data 2.7, a minor version release of Ember Data, is released. This release represents the work of over 27 direct contributors, and over 103 commits.

Ember Data 2.8 beta.1, the branch of Ember Data that will be released as stable in roughly six weeks, is also being released.

Blueprint Changes

In Ember Data 2.5 there was a change made to the blueprints to use module paths when importing instead of importing the default DS namespace. At the time this was thought to be a minor change and did not receive much scrutiny. However, in time the Ember Data team has discovered that the changes to the import statements in the blueprints have made it more confusing for both new and experienced Ember developers.

In Ember Data 2.5 and Ember Data 2.6 the following generator command for building a model:

ember generate model post content isDraft:boolean comments:has-many user:belongs-to

It would generate the following blueprint:

  
      app/models/post.js
    


  
  import Model from 'ember-data/model';
import attr from 'ember-data/attr';
import { belongsTo, hasMany } from 'ember-data/relationships';

export default Model.extend({
  content: attr(),
  isDraft: attr('boolean'),
  comments: hasMany('comment'),
  user: belongsTo('user')
});

app/models/post.js
1 2 3 4 5 6 7 8 9 10	import Model from 'ember-data/model'; import attr from 'ember-data/attr'; import { belongsTo, hasMany } from 'ember-data/relationships'; export default Model.extend({ content: attr(), isDraft: attr('boolean'), comments: hasMany('comment'), user: belongsTo('user') });

Ember Data 2.7 the same command will now generate the following blueprint:

  
      app/models/post.js
    
  import DS from 'ember-data';

export default DS.Model.extend({
  content: DS.attr(),
  isDraft: DS.attr('boolean'),
  comments: DS.hasMany('comment'),
  user: DS.belongsTo('user')
});

app/models/post.js
1 2 3 4 5 6 7 8	import DS from 'ember-data'; export default DS.Model.extend({ content: DS.attr(), isDraft: DS.attr('boolean'), comments: DS.hasMany('comment'), user: DS.belongsTo('user') });

The main difference is the blueprints no longer use the paths to import specific modules. We have found that encouraging users to omit the paths results in better defaults for both new and experienced Ember developers. The simpler import DS from 'ember-data'; statement has less room for typos and other errors and is easier to developers to remember so they do not need reference documentation whenever they want to add a new import.

This change only impacts the blueprints that are generated when using the ember-cli generate command. Code that is written to use the path imports will still continue to work and be supported until at least Ember Data 3.0.

The Ember Data team will also be releasing patch releases to Ember Data 2.5 and 2.6 to update their blueprint generators to match Ember Data 2.7.

Changes in Ember Data 2.7

`ds-boolean-transform-allow-null` #4022

Allow null/undefined values for boolean attributes via attr('boolean', { allowNull: true })

  
  // app/models/user.js
import DS from 'ember-data';

export default DS.Model.extend({
  email: DS.attr('string'),
  username: DS.attr('string'),
  wantsWeeklyEmail: DS.attr('boolean', { allowNull: true })
});

`ds-links-in-record-array` #4263

This feature exposes a links object on a RecordArray. This can be used to load additional links when present in the response JSON-API document.

  
  store.query('post', { isRecent: true }).then((posts) => {
  posts.get('links.next');
});

Thanks to @danmcclain for implementing this feature.

Upcoming Features in Ember Data 2.8.beta-1

`ds-improved-ajax` #3099

The ds-improved-ajax feature was originally planned to be released in Ember Data 2.7. However, feedback from the beta found that many people are overriding ajax() to change the protocol of the adapter and the new methods added in made ds-improved-ajax made this usecase harder to achieve. The Ember Data team has decided to delay the ds-improved-ajax feature flag until the Ember Data 2.8 release while improving the API for this usecase.

The ds-improved-ajax feature adds new public methods to DS.RESTAdapter, which allow to customize the properties of a request:

methodForRequest to get the HTTP verb
urlForRequest to get the URL
headersForRequest to get the headers
dataForRequest to get the data (query params or request body)

The params hash passed to those methods has all the properties with which the corresponding find, createRecord, findQuery, ... calls have been invoked: store, type, snapshot(s), id(s) and query. The requestType property indicates which method is requested; the possible values are:

createRecord
updateRecord
deleteRecord
query
queryRecord
findRecord
findAll
findMany
findHasMany
findBelongsTo

Performing the actual AJAX request is handled by the makeRequest method, which is similar to the existing ajax method: it makes the request using jQuery.ajax and attaches success and failure handlers.

Say your API handles creation of resources via PUT, this can now be customized as follows:

  
  // adapters/application.js
import DS from 'ember-data';

export default DS.RESTAdapter.extend({
  methodForRequest(params) {
    if (params.requestType === 'createRecord') {
      return "PUT";
    }

    return this._super(...arguments);
  }
});

Thanks to @pangratz for implementing this feature.

For more details on changes in the 2.8 beta, please review the Ember Data 2.8.0-beta.1 CHANGELOG.

Ember.js 2.7 and 2.8 Beta Released

2016-07-25T00:00:00+00:00

Ember.js 2.7, a minor version release of Ember with backwards compatible changes, is released today.

Ember.js 2.8 beta is also being released today. This branch will be released as stable in roughly six weeks and will then go on to be the next LTS release roughly six weeks after that.

Changes in Ember.js 2.7

Ember 2.7 introduces one new backward compatible API:

`Ember.computed.uniqBy`

In general, the core team is hesitant about adding any new computed macros or array prototype extensions to the framework. Instead, we encourage developers to adopt an addon such as ember-cpm if they desire an expanded list of macros.

However contributor @seanjohnson08 correctly pointed out there is a logical gap in the APIs Ember provides today. Although each of find, map, filter, and reject have a comparable xxxBy method (for example findBy) no comparable method exists for uniq.

Ember 2.7 adds uniqBy as an computed property macro. For example:

  
  import Ember from 'ember';

export default Ember.Component.extend({
  accidents: Ember.computed(function() {
    return [{
      description: 'Flipped over',
      car: { id: 1, make: 'Saturn' }
    },{
      description: 'Aliens',
      car: { id: 2, make: 'Toyota' }
    },{
      description: 'Road rage',
      car: { id: 1, make: 'Saturn' }
    }];
  }),
  carsInAccidents: Ember.computed.mapBy('accidents', 'car'),
  uniqueCarsInAccidents: Ember.computed.uniqBy('carsInAccidents', 'id')
});

uniqBy is also added as an array method. For example:

  
  import Ember from 'ember';

export default Ember.Component.extend({
  accidents: Ember.computed(function() {
    return [{
      description: 'Flipped over',
      car: { id: 1, make: 'Saturn' }
    },{
      description: 'Aliens',
      car: { id: 2, make: 'Toyota' }
    },{
      description: 'Road rage',
      car: { id: 1, make: 'Saturn' }
    }];
  }),
  uniqueCarsInAccidents: Ember.computed('accidents.@each.car', function() {
    return this.get('accidents').mapBy('car').uniqBy('id');
  })
});

For more information on these methods, see the API docs for the computed macro, API docs for the array method, and PR #12875 introducing these changes.

Notable Deprecations

The following deprecations are scheduled for release with Ember 2.7:

Ember.Backburner was private throughout the Ember 2.x series and will be removed after Ember 2.8, as mentioned in the deprecation guide.
Ember.Binding has not been needed for some time and is deprecated in favor of computed properties and services (depending on what you were binding to). It will be removed in Ember 3.0. See the deprecation guide for more details.

For more details on changes landing in 2.7, review the Ember.js 2.7.0 CHANGELOG.

Ember.js 2.8 Beta

Ember 2.8 beta introduces the following new backward compatible APIs:

Engines

As described in the RFC, "engines allow multiple logical applications to be composed together into a single application from the user's perspective."

The best way to use this feature in your apps is through the ember-engines addon. To get started, check out the excellent guides written by @trentmwillis.

This release will introduce a set of low-level APIs for the core functionailty along with the ususal semver guarentee. While the ember-engines addon itself remains expermental, the introduction of these public APIs means that ember-engines is now usable with Ember.js 2.8 beta.

Until now, none of the engine-related classes and hooks in Ember have been exposed publicly. However, starting with Ember 2.8, the following APIs will be made public:

Ember.Engine class - The base class for Ember.Application. Its only public interface is related to initializers and instance initializers, which is then inherited by applications.
Ember.EngineInstance class - The base class for Ember.ApplicationInstance.
mount keyword - Allows for the mounting of routeless engines in templates. This keyword currently only takes one argument, the name of the engine.
mount router DSL - Allows routable engines to be mounted at a location in a route map.

By making these APIs public, ember-engines and other addons will be able to access them without a feature-flag in a (soon-to-be) stable release of Ember. By accessing only public interfaces in Ember, an addon won't need to rely on private overrides and can provide as stable an experience as possible.

`Enumerable#includes` and `Array#includes`

In an effort to remain inline with ES standards, the methods Enumerable#contains and Array#contains have been deprecated in favor of the new methods Enumerable#includes and Array#includes.

Thanks to @alexspeller for the RFC that proposed this change.

Thanks as well to @bmeurant for the PR that implemented the change.

`Ember.String.isHTMLSafe`

The new method Ember.String.isHTMLSafe detects if a string was decorated using Ember.String.htmlSafe.

For example:

  
  var plainString = 'plain string',
    safeString = Ember.String.htmlSafe('<div>someValue</div>');

Ember.String.isHTMLSafe(plainString); // false
Ember.String.isHTMLSafe(safeString);  // true

Thanks to @workmanw for the RFC that proposed this new API, as well as the PR that implemented it.

On a related note, please create safe strings with Ember.String.htmlSafe instead of the deprecated Ember.Handlebars.SafeString. See the deprecation guide for details.

`Ember.Test.checkWaiters`

Thanks to @rwjblue and @krisselden for implementing this method.

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

Ember Blog

Ember.js 2.8-LTS, 2.9 and 2.10 Beta Released

Ember.js 2.8-LTS

Ember.js 2.9

Ember.js 2.10 beta

Ember.js 2.8 and 2.9 Beta Released

Ember.js 2.8

LTS Candidate

Engines

Other Notable Features

Enumerable#includes and Array#includes

Ember.String.isHTMLSafe

Ember.Test.checkWaiters

Ember.js 2.9 beta

Glimmer 2

Compatibility First

New Template Serialization Format

Performance

Future Work

Thank You!

Ember Node.js LTS Support

What does support mean?

How We Drop Support

Node.js 0.10 & Node.js 0.12

Recommended Version

Future Plans

Announcing The Glimmer 2 Alpha

🔑 A Key Milestone 🔑

🚀 A Note On Performance 🚀

🎁 A Whole Lot More To Come 🎁

❤️ A Big Thank You ❤️

📚 Further Reading/Watching 📚

Ember Data 2.7 and 2.8 Beta Released

Blueprint Changes

Changes in Ember Data 2.7

ds-boolean-transform-allow-null #4022

ds-links-in-record-array #4263

Upcoming Features in Ember Data 2.8.beta-1

ds-improved-ajax #3099

Ember.js 2.7 and 2.8 Beta Released

Changes in Ember.js 2.7

Ember.computed.uniqBy

Notable Deprecations

Ember.js 2.8 Beta

Engines

Enumerable#includes and Array#includes

Ember.String.isHTMLSafe

Ember.Test.checkWaiters

`Enumerable#includes` and `Array#includes`

`Ember.String.isHTMLSafe`

`Ember.Test.checkWaiters`

`ds-boolean-transform-allow-null` #4022

`ds-links-in-record-array` #4263

`ds-improved-ajax` #3099

`Ember.computed.uniqBy`

`Enumerable#includes` and `Array#includes`

`Ember.String.isHTMLSafe`

`Ember.Test.checkWaiters`