3 ms·

So true. This reminds me of one of my favorite tidbits from another vdom framework’s documentation, in which using the equivalent of shouldComponentUpdate is ge

by jsf01 6y ago

So true. This reminds me of one of my favorite tidbits from another vdom framework’s documentation, in which using the equivalent of shouldComponentUpdate is generally considered to be an antipattern. Whereas in React, it seems idiomatic to just memoize and throw in shouldComponentUpdate wherever you can as much as you can. https://mithril.js.org/lifecycle-methods.html#avoid-premature-optimizations https://mithril.js.org/lifecycle-methods.html#avoid-prematur...

onion2k 6y ago
From the mithril docs you linked to: "You should only use onbeforeupdate to skip diffing as a last resort. Avoid using it unless you have a noticeable performance issue." From the React docs (https://reactjs.org/docs/react-component.html#shouldcomponentupdate https://reactjs.org/docs/react-component.html#shouldcomponen...): "Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior. [...] This method only exists as a performance optimization." Both framework developers are telling users the same thing.
- jsf01 6y ago
  That’s a good point. There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate while mithril’s tends to advise against those methods. The blog post behind this thread is a prime example.
  - dragonwriter 6y ago
    > There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate I haven't seen that. > The blog post behind this thread is a prime example. But it's...not at all an example of what you describe. The blog post explains how things work and how to optimize, it doesn't encourage optimizing without demonstrated need, and the "even better" optimization approach it suggests isn't using memoization or shouldComponentUpdate, but instead paying attention to the basic component structure.
petetnt 6y ago
> Whereas in React, it seems idiomatic to just memoize and throw in shouldComponentUpdate wherever you can as much as you can. Absolutely not, wrapping everything in shouldComponentUpdates probably leads to worse performance as the comparison checks are more expensive in hot paths than just rendering everything again (same with PureComponents and so on).

by jsf01 6y ago

onion2k 6y ago

From the mithril docs you linked to: "You should only use onbeforeupdate to skip diffing as a last resort. Avoid using it unless you have a noticeable performance issue." From the React docs (https://reactjs.org/docs/react-component.html#shouldcomponentupdate https://reactjs.org/docs/react-component.html#shouldcomponen...): "Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior. [...] This method only exists as a performance optimization." Both framework developers are telling users the same thing.

jsf01 6y ago
That’s a good point. There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate while mithril’s tends to advise against those methods. The blog post behind this thread is a prime example.
- dragonwriter 6y ago
  > There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate I haven't seen that. > The blog post behind this thread is a prime example. But it's...not at all an example of what you describe. The blog post explains how things work and how to optimize, it doesn't encourage optimizing without demonstrated need, and the "even better" optimization approach it suggests isn't using memoization or shouldComponentUpdate, but instead paying attention to the basic component structure.

petetnt 6y ago

> Whereas in React, it seems idiomatic to just memoize and throw in shouldComponentUpdate wherever you can as much as you can. Absolutely not, wrapping everything in shouldComponentUpdates probably leads to worse performance as the comparison checks are more expensive in hot paths than just rendering everything again (same with PureComponents and so on).