5 ms·
I don't think the class-based examples look deliberately inflated. > or example, one of them has 4 setState() calls after each other instead of combining them.
by epidemian 7y ago
I don't think the class-based examples look deliberately inflated.
> or example, one of them has 4 setState() calls after each other instead of combining them.
You would still need one line for each state property set:
this.setState({
data: newData,
dimensions: getDimensions(),
xScale: getXScale(),
yScale: getYScale(),
})
(Unless you were to compress all of that into one line...)
In fact that makes things longer in terms of LoC. A bit less noisy though, that'd be true.
> Another manually performs deep equality checks for each key instead of using some library/helper.
Yeah well, I think this is completely fair if you want to "compare oranges with oranges". If the author were to include external libraries, then they would no longer be comparing "Reach with hooks" with "classic React", but with "classic React + some X library" instead.
- mharroun 7y agoWhy not put the function calls into the render? And only decide to rerender on state change. You could push nearly all that logic back into extends Purecomponent
- Klathmon 7y agoThey point out that the get* functions are supposed to be "computationally expensive", and you don't want something like that in your render method. But also in either the current or near future versions of react, with Suspense and concurrent rendering, the render method may be called multiple times over the course of a single render. So if any of those functions aren't entirely pure, there is a good chance there will be bugs from that.