0

Looking at Facebook's Flux TodoMVC example (https://github.com/facebook/flux/tree/master/examples/flux-todomvc/) makes me wonder how this approach scales.

In the example the store is updated onBlur/Enter keypress of a new entry, but what if we wanted to update an existing entry on keypress? i.e. you type something in an input and this is persisted to the store.

The store's contents (todo list) is set as state at the highest level since the whole app needs it, this is re-set whenever the store changes.

How does this scale? It seems like it would be inefficient to check if every component needs to re-render when in all likelihood probably nothing does (you're just editing text and that item is the only thing which needs updating).

Is this approach OK to use for a real app, or are there optimisations to keep in mind to make this scale efficiently?

enter image description here

Dominic
  • 62,658
  • 20
  • 139
  • 163

1 Answers1

1

Every component has the shouldComponentUpdate method that will run to determine if a component actually should update when it receives new props. By default, this just returns true.

If you implement that method well on your components, then the architecture you laid out is very efficient and will scale well as your app grows.

See also: PureRenderMixin https://facebook.github.io/react/docs/pure-render-mixin.html

Crob
  • 14,807
  • 3
  • 31
  • 28
  • Thanks, good to know that it stops the updating of subtree components too, should be able to make it nicely efficient with that. – Dominic Jun 11 '15 at 21:06
  • It starts to get complicated when your props at a high level include objects because it's difficult to tell if an object has changed. This is where immutable objects really help. For more information, check out this talk on Immutable.js from ReactConf. Lots of good stuff. https://www.youtube.com/watch?v=I7IdS-PbEgI – Crob Jun 11 '15 at 21:17
  • Thanks watching it, need to get my head around immutable apps – Dominic Jun 11 '15 at 21:32