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.
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.
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.
@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.
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. npm and 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 (didReceiveAttrs/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 PromiseProxy
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
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!
