A lightweight reactive data library for javascript applications. Designed over composable primitives.
This release removes code deprecated during 4.x.
🎵 We could stay like this forever.
It might be the last release of the cycle, but this release comes packed with goodies, so here we'll try to unpack a bit of what's changed.
First, while all addons are still shipping as v1-addons, they now look a lot like v2-addons. We're referring to this as "v1-lite". We pre-build them with rollup leaving only the most minimal babel step to be done when included in your app. Generally this should result in applications seeing improved build times and vastly improved embroider support.
There are still a few blocking issues in ember-auto-import and embroider before EmberData will be able to flip the switch and ship its packages as v2-addons, but that's what is left at this point: a switch to flip. Many thanks to @richgt for his efforts to help us on this journey.
Numerous APIs associated with the Cache, Notifications, Identity Management, and Record Lifecycle have new or improved docs. All packages have had their package overviews updated (some extensively, a few just a bit -- for now), and all packages now have a detailed README.
Deprecation documentation is now written inline alongside the flags that may be used to control granular deprecation stripping. Deprecation documentation will also continue to be added to the deprecation guides, though as of yet the 4.x guides have not been added there (we'd love help with this!).
A major focus of the 5.x cycle will be on refining and polishing the documentation for Polaris. A Quest issue has been opened and we'd love your help!
This package introduces the RequestManager, a package that can be used independently (but also comes bundled with ember-data
) that re-envisions how data fetching is managed for both EmberData and applications more broadly.
You may want to peruse the RFC or head over and read its documentation
With this release, all existing request flows in EmberData utilize the RequestManager. While Adapters and Serializers will continue to work via the legacy-handler, these concepts are now entirely optional and users should expect that over the course of the 5.x series as the new request management story is further polished that these legacy concepts will be deprecated and removed from the recommended experience. They will, however, likely live on much longer since their implementation is now as an integration into the request-pipeline of the future and as such is something an application could choose to integrate and continue using.
In addition to subscribing to notifications for individual resources, the notification service now enables subscribing to resource added/removed events and Document added/removed events.
EmberData now uses native promises for all promise APIs instead of RSVP Promises. This can have some unexpected timing affects, there's an overview here
What this means in effect is that store.request
is now a much ... much more powerful API than store.query
. Requests are capable of providing a cache-key or being cached by URL, with full lifecycle control and notification subscriptions. Documents are a first-class citizen of the Cache and EmberData more broadly, we are no longer just a resource-cache. For the full motivations and a discussion of all the various capabilities this unlocks we recommend reading the RFC
To go with this, the JSON:API
cache previously provided by @ember-data/record-data
is now upgraded to the 2.1 spec and available as the @ember-data/json-api
package. While this cache does not yet implement the full suite of cache 2.1 APIs, support for all Cache 2.1 APIs has been added to the store.
@ember/error
to native Error (@chriskrycho)Fixes a memory leak in SSR/Tests and Infinite Recursion bug in develop when yielded/awaited in an ember-concurrency task.
Fixes a memory leak in SSR/Tests and Infinite Recursion bug in develop when yielded/awaited in an ember-concurrency task.