Future planning / roadmap of Ember data?

I totally agree that finishing Ember Data is an important part of the Ember project. A number of members of the core team (Tom Dale, Peter Wagenet, Stefan Penner and I) have been dedicating a lot of time lately to getting it over the finish line. You can follow our progress on the jj-abrams branch. Teddy Zeenny, who’s been doing most of the work on the extension lately, has also been doing work on data support in the extension. You can follow his work at Add Data tab to the extension by teddyzeenny · Pull Request #38 · emberjs/ember-inspector · GitHub.

I personally plan to get that branch merged at the same time as Ember 1.0 final, at the end of this month.

Some of the goals of the branch are:

  • Simplify the state machine implementation to improve load performance. (DONE)
  • Provide escape valves for all state machine events. Most notably, this means the addition of a merge hook on models that can be used to support updates from the server when a record is dirty or in flight. This has been a major gotcha for people trying to support streaming. (ON DECK)
  • Eliminate “lazy materialization”, which adds a lot of complexity to the codebase with very little practical benefit. (IN PROGRESS)
  • Dramatic simplification of the deserialization process and document the format that Ember Data is expecting so that it’s easy to munge the data you get back from your server and push data into the store manually. (IN PROGRESS)
  • Full documentation and improvements of the primitives that Ember Data is built on, so you can get records in and out of the store even if some part of the process needs to be custom (IN PROGRESS).
  • Documentation of the usage of Ember Data, as well as an explanation of how to do streaming, work with raw Ajax requests, errors and invalidation, and other common requests. (IN PROGRESS)
  • Update the API to future-proof for ES6/AMD modules (MOSTLY DONE)
  • Update the API to fully support App.reset() (for testing and log out) (MOSTLY DONE)
  • Improved consistency in usage of promises (IN PROGRESS)

I agree that these features need to be supported, at least via common patterns. In terms of “complex transactional rollback”, I consider the ability to press cancel on a form and revert back to the state before you entered the form to be a basic feature that most apps will need.

Yes. This has been a historical problem. As more members of the core team have become directly involved in Ember Data day-to-day, I hope to see this problem get resolved. Already, Peter Wagenet has been instrumental in closing and responding to a large number of out-of-date pull requests over the past few weeks.

This was a major topic of the Ember Core meeting we had a few weeks ago. Ember Data will be getting the attention it needs and deserves.

I still believe that a robust data solution is a key part of the Ember project. As @workmanw pointed out, because of how much Ember does for you, people expect Ember to have an “M” layer, even if they accept “just use your JSON objects” in Angular. People expect Ember to do more for them, and that’s something I am confident we can deliver on.

Once we merge the branch, we’ll focus our energies on how to increase the circle of contributors beyond the core team. Making Ember Data easier to contribute to will be a critical part of its long term success.

17 Likes