Reduce dependency on ArrayComputed and ReduceComputed #10582
Conversation
wagenet
force-pushed
the
array-computed-removal
branch
from
de9aa25
to
b1f9679
Compare
|
The great culling begins |
YESSSSSS |
|
@fivetanley was the in place modification an issue for you? I was thinking of that as a slight loss (though worth it because of reduced complexity). |
wagenet
changed the title
| import compare from 'ember-runtime/compare'; | ||
|
|
||
| var a_slice = [].slice; | ||
|
|
||
| // TODO: Consider putting this with other array shims |
There was a problem hiding this comment.
In 2.0.0 it seems like there might be an opportunity to take compat ES5 stuff into an 'ember.compat.js'. This way developers can shed even more weight if they only support evergreen browsers. It also draws a clean line for deprecations when ember decides not to support non ES5 browsers.
There was a problem hiding this comment.
I definitely think there is some improvement we can do here. I don't want to get too caught up on that stuff in this PR.
In theory? Absolutely not, it's a great idea. In practice? It was the source of many zalgo bugs and random test failures. I know @kategengler ran into this a lot too. |
|
❤️ I'm very excited for this, I've been avoiding any of the computed macros that used arrayComputed and reduceComputed because of running into many of the bugs around them. |
wagenet
force-pushed
the
array-computed-removal
branch
from
b1f9679
to
eba968f
Compare
|
Now that the glimmer work has landed, this is ready to be considered. @wagenet - Can you rebase? |
|
cc @hjdivad |
|
Hello, I would like to be confirmed if arrayComputed / reduceComputed features will still be present in future Ember versions, at least as compatible modules: I'm into a complex App where this feature seems essential to not overwhelm the UI. Are there really irremediable bugs in arrayComputed / reduceComputed, or is this mostly due to an incomplete understanding of such complex methods from some in the Ember community? As I'm quite new to Ember I may miss some things, are there any other solutions which would allow to do complex operations on a huge array and not re-calculate everything when one of its element's properties changes? Thanks. |
|
superseded by: #11513 |
The bugs are quite tricky, luckily the new glimmer engine can handle re-renders of total array changes quite quickly. Obvious extremely large sets of data may have some issues with our new approach. For those i suspect a better experience would be using something like http://square.github.io/crossfilter/. I am sure there are other solutions. Once this lands, I'll put some cross filter examples together. I suspect it would make a great ember example :) |
|
Did these examples happen to get made? I'm facing performance issues due to these changes and am looking for an alternative. In my case i have arrays of 1000 items that are constantly being added to in a real time scenario. |
|
I don't believe so |
|
crossfilter seems to be a good solution. I don't realize if https://github.com/Wildhoney/EmberCrossfilter can be adapted easily to work with Ember 1.12. |
:) |
DO NOT MERGE YET
This removes the dependency of the Ember.computed array macros on ArrayComputed and ReduceComputed. The new path is currently slower but significantly less complex. Once Glimmer is merged (#10501) the slowness introduced by this PR is unlikely to cause problems.
This PR also removes all internal dependencies on ArrayComputed and ReduceComputed allowing these methods to be removed entirely from core. (If desired, we can make a plugin for them.)
KNOWN DIFFERENCES/ISSUES
Ember.Aanymore.unionandintersectmay be different than before. I think this is acceptable since sorting isn't part of the API contract for these.TODO