Improve node replace algorithm

[diogofcunha]

Same profiling on Large Collection example(increasing the number of rendered nodes to be ~230k) showed the following results:

replaceNodeFromTree

master

For a simple action replaceNodeFromTree takes ~500ms to run, this makes the UI look strange

here

As the image shows the time that replaceNodeFromTree takes to run is now residual and the burden is on getFlattenedTree

It means that the next step will be to try to add some kind of memoization to getFlattenedTree so that it only needs flatten the strictly necessary nodes and keep the old ones in memory while still possible

[codecov-io]

Codecov Report

Merging #20 into master will decrease coverage by 0.98%.
The diff coverage is 92.85%.

@@            Coverage Diff             @@
##           master      #20      +/-   ##
==========================================
- Coverage   97.47%   96.49%   -0.99%     
==========================================
  Files          14       14              
  Lines         119      114       -5     
==========================================
- Hits          116      110       -6     
- Misses          3        4       +1

Impacted Files	Coverage Δ
src/selectors/nodes.js	96.15% <92.85%> (-3.85%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bc3f89f...55d4df7. Read the comment docs.

[diogofcunha]

Optimizations for getFlattenedTree seem irrelevant and premature at this moment in time, 250k elements is a fair number of nodes to support at this moment in time.