[BUGFIX release] Deprecate @each as a leaf node.#11994
[BUGFIX release] Deprecate @each as a leaf node.#11994rwjblue merged 12 commits intoemberjs:stablefrom
@each as a leaf node.#11994Conversation
c36681a to
a656bdf
Compare
See: RFC/issue emberjs#80 - emberjs/rfcs#80 (cherry picked from commit 97e4441)
(cherry picked from commit 2cccf86)
There are no alternative way to `Ember.merge` in Ember world. But it is useful and widely used from other library. For example: * Ember Data: https://github.com/emberjs/data/blob/v1.13.7/packages/ember-data/lib/core.js#L29 * Liquid Fire: https://github.com/ef4/liquid-fire/blob/v0.21.0/app/transitions/scroll-then.js#L19 So this method may be public until `Object.assign` can be used natively. (cherry picked from commit 1c79810)
(cherry picked from commit 281b8ca)
(cherry picked from commit 1f50e49)
(cherry picked from commit 4dee6c5)
Closes emberjs#11989 [ci skip] (cherry picked from commit c3b61b8)
- compact - every - forEach - without - sortBy Closes emberjs#12004 [ci skip] (cherry picked from commit d9c3027)
This is fixed properly in canary/beta, but required changes to the build system so I'm just patching this here to make it easier to get the right live test page working.
a656bdf to
56d72e9
Compare
* `TrackedArray` and `SubArray` are still used by the RC/AC implementation in 1.13.x,
but it should not trigger a `TrackedArray` deprecation.
* Fix a few tests that were using `{{with}}` and `controller=`.
554a012 to
63a3e06
Compare
Update stable version with a deprecation when using `foo.@each` as a dependent key. This code is removed on beta (2.0.0) and canary (2.1.0) branches already.
63a3e06 to
d623cf9
Compare
[BUGFIX release] Deprecate `@each` as a leaf node.
|
@rwjblue just out of curiousity. Is it still possible to track a sub-property of things in the array that are one level deep. I assume what used to be
is changed to
and all is well? |
|
@rauhryan other way around:
|
|
thanks for clarification @stefanpenner I'll pass it on to the team |
|
@stefanpenner How about observing ANY property changes on things like |
|
@icecoldmax I don't believe that is a feature. @each and [] are for arrays and array proxies. Not objects or object proxies. I'm dubious that this works as you describe. |
|
@stefanpenner I think I described it wrong. Let me try my checkbox example better: Let's say these are now iterated over as a list of checkboxes where checking it updates the Is this bad practice? |
since there is a map, proxiedFoos is always an array and the following should be true.
|
|
I found that the easiest way to compare these various computed properties was live. I was slightly confused about the behavior. Here is a twiddle: http://ember-twiddle.com/02ddca9b6c89f2f8f92b. TLDR, from my understanding:
|
|
@stefanpenner @aortbals Thanks for the clarification. Is there actually a way to do what I'm thinking of? Say you have an array of objects, each with a ton of attributes and you want to observe when any of their properties change. Any way other than just observing/computing on |
no – only granular changes are currently supported. |
Update stable version with a deprecation when using
foo.@eachas a dependent key. This code is removed on beta (2.0.0) and canary (2.1.0) branches already.