Skip to content

v4.12.0 - Can't Cache This!
Compare
Choose a tag to compare
@runspired runspired released this 09 Apr 00:30
· 1144 commits to main since this release
v4.12.0
431c81b

MC Hammer Dancing to Can't Touch

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.

A Big Step Towards Modern Javascript Build Tooling Support

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.

Documentation

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!

@ember-data/request has its first Stable Release!

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.

The Notifications Service has Expanded Capabilities

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.

Promises are now Native Promises

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

The Cache 2.1 Spec is Implemented

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.

Changelog

🚀 Enhancement

🐛 Bug Fix

  • #8517 fix: ensure cache-handler works as expected (@runspired)
  • #8511 updates to lifetimes service and CacheHandler install (@runspired)
  • #8453 chore: fix ArrayLike.setObjects deprecation message (@runspired)
  • #8435 fix: de-cycle ember-concurrency access of promise (@runspired)
  • #8400 fix: deprecated record-array reject use callback (@mrloop)
  • #8399 fix: deprecated record-array rejectBy use optional value if supplied (@mrloop)
  • #8436 perf: fix: eliminate SSR/Test memory leak (@runspired)
  • #8432 fix: ensure classic computed chains support (@runspired)
  • #8410 fix: add better embroider test and fix embroider compat (@mkszepp)
  • #8354 fix: improve error/deprecation messaging for inverse fields (@runspired)
  • #8348 fix: don't use isEqual from @ember/utils for comparing cache values (@runspired)
  • #8345 fix: give more meaningful error if id matches but is number instead of string (@runspired)
  • #8344 fix: improve object stringify and verbiage for relationship identifier errors (@runspired)
  • #8338 fix: json-api-cache should reflect dirty state during save (@runspired)
  • #8335 fix: .changedAttrs should be empty if no local mutations exist (@timmorey)
  • #8346 fix: Schema.eachTransformedAttribute API should match Model.eachTransformedAttribute (@runspired)
  • #7900 fix: rollbackAttributes|unloadRecord during hasMany forEach should not error (@runspired)
  • #8336 fix: dont notify RecordArrayManager if deletion already accounted (@runspired)
  • #8323 fix: Only remove object(s) from record array if in collection #8318 (@rossketron)
  • #8341 fix: add meaningful error and proper rejection for id assertion during createRecord commit (@runspired)

🚿 Deprecation Removal

📝 Documentation

🥅 Test

🏠 Internal

Committers: 9

Assets 2
Loading