Memoizing a leaf component probably isn't worth doing unless it has some incredibly complex logic in it.
Just like memoizing a single reduce operation probably isn't worth it either.
The React community is the absolute worst offender for premature optimization.
Measure first, then optimize.
This sounds like good advice, but from experience I've found that optimizing code by adding things like memoization after you've discovered it's too slow in the context of an app is a lot harder than than writing something that's efficient to start with, especially if a feature is mature and other parts of the code are resistant to change. There's a balance to strike between spending time writing optimal code and actually shipping, but if there are low-hanging fruit available and you choose not to take advantage of them you'll probably regret it.
As someone who spent weeks trying to optimize a react native app, believe me, this is not going to go the way you think it is. It never will. Not without rewriting half of your app and earning the ire of your customers for being a slow hog along the way.
> Memoizing a leaf component probably isn't worth doing
It isn't when you only have 10 components. By the time you have a thousand of them in a big app, you will have a thousand small performance paper cuts in you application. And they will bleed your app while you can do nothing but watch.
But I have used hundreds of components in some apps. Most of them were big enterprise apps that had a lot of input fields for data entry. Given the was data entry works in React, especially with the general form practices, it was a nightmare when I first started and was a follower of the entire premature optimization gospel.
For a more similar and public example, just have a look at how sluggish the jira webapp feels.
They are also the worst for "no optimization it takes 5 seconds to load" pages.
Case in point: why are (or were?) anonymous functions frowned upon in React props?
Is it because of the penalty involved with creating a function on each render call? Of course not - my phone can do 19mln of those a second.
It's because the VDOM sees a reference change, so it re-renders the component.
Obviously if there's a performance penalty, it's because of the latter, but I heard the former before as an argument in a discussion.
I also wrote an article about this, if you can write efficient code without sacrificing readability I think it's worth the (small) effort.
The submitted article is fairly similar in some sense. You address optimization but skip out on the most important step of optimizing - measuring what you need to optimize. Tacking memo, ref and key onto everything isn't free and if those parts of your application weren't the problem you're actually making it slower.
It makes the same claim about code reuse, with the reasoning that code is more likely to be JIT compiled if it's a single hotspot rather than two, well, 'warm spots'. Again it doesn't properly back up this reasoning.
https://mithril.js.org/lifecycle-methods.html#avoid-prematur...
"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#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.
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.
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).
It's probably good advice to avoid lots of custom shouldComponentUpdate logic though. That's smelly.
This is contradictory
The whole silly meme of "premature optimization is the root of all evil" is a 100% useless statement. Of course, you shouldn't do it yet if it's premature- that's the definition of premature.
But if it's almost the same amount of effort to write faster code from the get go- especially if you KNOW the code will be speed-sensitive, then you should absolutely try to do the fast thing over the slow thing. That seems obvious...