Open Raynos opened 10 years ago
@Raynos ive hit this bottleneck hard, so i'm temporarily using @mmckegg transaction workaround, but cant imagine this is ideal... any ideas of leads of other possible implementations? new to immutability, but happy to do a little research w/ some direction
i saw there is a debounced observ from dominic tarr which is at least a performance improving option, but obviously this isnt built into all the many types of observ ...
@cellvia Honestly the best tip i can suggest is to use mutable data structures boxed in a shallow observ
.
And then control when to "update()" the observ
to avoid aggressive re-renders and aggressive shallow cloning up the tree.
It's even better to put it as a top level field on your state
.
So youre saying put an intentionally mutable array into a observ
, update it as many times as needed, and manually call update when done? are you globally recommending this or just for arrays? just curious as it would seem to negate the whole intention w/ the single immutablity tree approach...
@cellvia
If you want to go fast; you have to use mutation. immutable tree + observ is a best effort sanity but has performance penalties.
There are kind of cute things we can do to make immutable faster, but mutation will always win.
Just like observ-hash we use
.slice()
to shallow copy arrays for every change.We should have alternative implementations of immutable data structures with benchmarks.
This can become a serious bottleneck in the implementation of application state.
cc @ljharb @Matt-Esch (any advice on immutable is appreciated)