0

I have an UI built in Flux/React that mimics an OS windows system. User can move, minimize, and resize windows but also drag'n'drop icons between windows. I have main Desktop component which polls LayoutStore and builds children based on layout data.

It turns out however that rerendering the virtual DOM tree with more elements takes long enough to impair app responsiveness sometimes which is bad for transition animations. I already gave up on updating state at 60fps - I just update layout store after user drops an element. I was thinking about ways to limit render calls since I know that most changes to the layout affect child components very selectively - there is low chance that a given layout state change affects more than one particular component.

What I came up with is keeping a dirty or stateVersion variable in LayoutStore for each larger component (i.e. a window) and passing it in props so that each component could check if it was affected very fast without worrying about complexity of state representation (no deep comparisons, immutable copies, etc.) Also I prefer the second way cause I can just bump component's stateVersion each time I mess with its properties and don't need to unset dirty back in the store after emitting change.

Since I'm very new to React - is it a sane approach given my constraints or is there a better standard solution?

konrad
  • 1,664
  • 2
  • 17
  • 36
  • You can check for changes in the life cycle method `shouldComponentUpdate` instead of keeping a dirty variable in state yourself. Furthermore, React is very fast, most likely your bottlenecks will be from other things than rerenders. – Henrik Andersson Sep 24 '15 at 18:29
  • I did plan to do the checking in `shouldComponentUpdate` method, the only hack would be to have additional property saying 'nothing changed really' or 'there was some change - please rerender your subtree'. I know react is fast and why it is so, but it still has to run all the stuff in my 'render' methods and it actually turned out to be a bit of a bottleneck - I'll look into optimizing that code as well, but abstaining from calling `render` looked like a lowest hanging fruit. – konrad Sep 25 '15 at 10:07
  • OTOH, after reading https://facebook.github.io/react/docs/advanced-performance.html I'm starting to believe that maintaining dirty flags in a tree structure will provide little advantage over using immutables for the node data. – konrad Sep 25 '15 at 10:27
  • 1
    @konrad I do the exact same thing like you: I have a 'revision' property on my models which I bump on every updated. Probably not "the react way", but it's simpler than having to mess with immutables and it's still a very fast method to detect changes in `shouldComponentUpdate`. Haven't discovered any drawbacks so far in my use cases. – Simon Sep 27 '15 at 11:56
  • @Simon Good to hear it works for you. It seems to work OK with a lot of siblings, eg. a table view, however if you have a tree structure you need to propagate the `version` change toward the root otherwise a subcomponent will never update obviously. Then, you may have more than one store that the component is listening to - it all can make versioning more complex than expected at the beginning and the simplicity advantage is all lost. – konrad Sep 27 '15 at 13:23
  • When I finish my project I'll write a proper answer for this myself but for now, this (https://www.youtube.com/watch?v=I7IdS-PbEgI) is an incredibly relevant (down to dirty checking) and incredibly interesting video on the topic. In short: use immutables to represent state as it should solve this and a few other problems more elegantly. – konrad Sep 27 '15 at 15:46

0 Answers0