There has been a trend of increasing instability in Ember Data over the last
few releases. Although instability in a complicated system is not surprising,
the level of stability has not been trending in the right direction. Changes
will be made to address this.
Examples that come to mind include:
These issues have a common theme: they involve relationship and state code that
combine complexity and underspecified behaviours.
Our high level plan for addressing this is:
- simplify the implementation
- express semantics more precisely
- extend testing to real-world applications sooner
To mitigate the risks associated with adding precision to previously
underspecified behaviour, we intend to add two safeguards.
Firstly, we will be testing against OSS applications in addition to Ember
Data’s test suite. In particular:
Secondly, we will partner with community members to test Ember Data during its
beta periods. This partnering will take several forms:
- Private application sharing with trusted Ember Data maintainers for a
limited number of apps
- Periodic, scheduled, Ember Data upgrade sessions from the currently released
version to the current beta. These sessions will be in an “office hour
style” block of time.
Fixes for the most serious issues have been backported to 3.2.1 and 3.3.1. If
you are upgrading now, please upgrade to 3.4.0-beta.2.
Together, we can improve things. Bug reports, minimal reproductions, and pull
requests are extremely helpful, but the importance of testing our
applications against betas can not be emphasized enough. Getting a tighter
feedback loop is exactly what will make 3.4, the upcoming LTS release, our most
successful one yet.
This kind of practical, proactive and clear communication is really awesome to see. Thank you!
Hey, I work on
travis-web and I’m excited to hear about this. Let us know if there’s any way we can facilitate testing the application with betas.
I’ve actually been struggling to keep it updated with later versions because of mysterious-to-me breakage, including an Ember Data snapshot/relationship problem that I couldn’t figure out within my timebox for updating. When I have another moment, I’ll see if it’s perhaps related to the bugs you mentioned.
This sounds great! Thanks for sharing.
There’s a pr up for OSS external partner testing for those who want to follow this side of the implementation.
@hjdivad Is it still recommended to upgrade to the latest beta if you’re upgrading now?
@HeroicEric yes, the current 3.4 beta is 3.4.0-beta.4. I’d recommend upgrading to that version. 3.4.0 will be released very soon so upgrading to 3.4.0-beta.4 today is very nearly upgrading to 3.4.0.
It is this behavior https://github.com/emberjs/data/issues/5575 that you experience. I think we should have released ember-data v4.0.0 for this because it needs change on all levels.
Just until Ember is changed to work with the new ember-data above v3.1.1 we need the classic behavior to fix your issue. I released ember-data-classic v3.4.0 to work around this for now. Hope it is fixed soon but the change may need Ember to change as well.
Please don’t publish forks on npm to work around issues. It’s easy for people to become confused about official packages and stability this way.
yarn can both install via github URLs, which works just as well without making the
npm registry more confusing.
As I’d mentioned to you earlier,
ember-power-select is relying on unspecified behavior, which is equivalent to relying on private API. That unspecified behavior was a bug.
There may be improvements that could be made to Ember Component lifecycle hooks (
didUpdateAttrs) to properly trigger when an object has been dirtied, but ultimately
ember-power-select should be able to fix the issue affecting you itself.
Proxies, by nature, are meant to be a stable wrapper around the content they proxy to. In the case of power-select, the library had accidentally come to rely on that proxy being torn down and re-created in situations it should not have been.
There are a few ways that power-select and/or users of power-select can resolve this:
- use a hook that does trigger (
willRender ) and check to see if the property has changed.
- install a computed property that watches the dependent keys appropriately.
- resolve async relationships before passing them into the component, instead of relying on
ember-power-select to unwrap the
We only needed to fork to get back the classic behavior for all our own projects and everybody who needs the classic behavior above ember-data 3.1.1 . We will try to follow the ember-data releases until this is resolved. It has in my opinion nothing to do with ember-power-select because it a breaking change without any documentation and warnings. ember-data just broke many projects without any deprecation path above version 3.1.1 It was this that will confuse more then this fork
See how to test this here
We hope a deprecation warning and upgrade path will be added soon.
I’ve been adding high level tests to ED as PRs whenever I’ve found what I thought were upgrade problems. I suggest everyone does this so that the test suite finds these issues before we do!