4 ms·

Hardly - they enforce the React philosophy more strictly. In an ideal system, Components receive props, modify internal state, and render idempotently based on

Hardly - they enforce the React philosophy more strictly. In an ideal system, Components receive props, modify internal state, and render idempotently based on these. The PureRender mixin is a way of saying "yes, this component conforms to the above constraints". Unfortunately, it's not always the case that the naive way of writing a Component will comply with the PureRender restrictions, so it's not enabled by default. It's not difficult, 99% of the time, to alter a Component to work properly with only minimal changes, and they aren't changes that make the Component code more confusing. ComponentShouldUpdate is a way of applying tree-trimming logic that React could not automatically know. Business logic and the like. When a Component implements componentShouldUpdate and returns false, it will prevent any children of that component being iterated in that loop. Ideally, componentShouldUpdate should just returning a Boolean value from state, rather than calculating it each time.

amelius 11y ago
> When a Component implements componentShouldUpdate and returns false, it will prevent any children of that component being iterated in that loop Yes, but when you alter 1 element of a list L, then L must be iterated (simply because it changed), so componentShouldUpdate() will return true for L. As a consequence, all elements of L will be checked. But you only changed one!
- richthegeek 11y ago
  I sort of see where you are coming from, but I can't see how it could be done any differently in an idealised system. If you change the elements in a set, you need to re-evaluate how that set is rendered. Wether you leave it to the elements to decide if they are to be altered, or have that logic in the set-handling code, the book-keeping (and related CPU time) still needs to occur? Either way, the proof is in the pudding: React is so insanely faster for this specific case than all other approaches.
  - omphalos 11y ago
    What should happen is that we do incremental computation, sort of like what's described here [1]. You ought to be able to declaratively specify that such-and-such collection maps to such-and-such elements. If you change just one element in the collection, change tracking built into an incremental computation framework should cause that one element to update. Logically, there's really no need to review the entire collection if just one element changes. Certainly the Virtual DOM is one way to let you declaratively write to the DOM and not worry about change tracking yourself. But it's not the most efficient way. Unfortunately this sort of thing has never been implemented in JavaScript (that I can find) so currently the Virtual DOM is probably our least worst choice, at the moment. [1] https://blogs.janestreet.com/introducing-incremental/ https://blogs.janestreet.com/introducing-incremental/
    - amelius 11y ago
      Yes, this is also the approach I was thinking about. Perhaps it is time somebody at Facebook gets the chance to develop the javascript variant of this technique, as it is a far more "correct" way of approaching the problem, from a Computer Science standpoint.

amelius 11y ago

> When a Component implements componentShouldUpdate and returns false, it will prevent any children of that component being iterated in that loop Yes, but when you alter 1 element of a list L, then L must be iterated (simply because it changed), so componentShouldUpdate() will return true for L. As a consequence, all elements of L will be checked. But you only changed one!

richthegeek 11y ago
I sort of see where you are coming from, but I can't see how it could be done any differently in an idealised system. If you change the elements in a set, you need to re-evaluate how that set is rendered. Wether you leave it to the elements to decide if they are to be altered, or have that logic in the set-handling code, the book-keeping (and related CPU time) still needs to occur? Either way, the proof is in the pudding: React is so insanely faster for this specific case than all other approaches.
- omphalos 11y ago
  What should happen is that we do incremental computation, sort of like what's described here [1]. You ought to be able to declaratively specify that such-and-such collection maps to such-and-such elements. If you change just one element in the collection, change tracking built into an incremental computation framework should cause that one element to update. Logically, there's really no need to review the entire collection if just one element changes. Certainly the Virtual DOM is one way to let you declaratively write to the DOM and not worry about change tracking yourself. But it's not the most efficient way. Unfortunately this sort of thing has never been implemented in JavaScript (that I can find) so currently the Virtual DOM is probably our least worst choice, at the moment. [1] https://blogs.janestreet.com/introducing-incremental/ https://blogs.janestreet.com/introducing-incremental/
  - amelius 11y ago
    Yes, this is also the approach I was thinking about. Perhaps it is time somebody at Facebook gets the chance to develop the javascript variant of this technique, as it is a far more "correct" way of approaching the problem, from a Computer Science standpoint.