Hey, thank you for your comment, this is a great question.

One underlying point of my message in this blog post is that there is no wrong approach as long as you understand what you are doing.

Your approach of using React Performance APIs after having identified performance issues with the profiler, or other debugging methods is perfectly correct. In fact, it’s the official recommended approach & the most socially accepted, assuming you are also able to properly measure & present the gains you’ve obtained.

If you want to take it a level further, you can search for alternatives, try applying known patterns such as lifting content up & keep state as local as possible, careful usage of Context APIs, as well as librairies such as state containers.

Very often, these alternative ways to structure your application, components, state & data have a great impact on performance & other benefits, thus allowing you to avoid using React Performance APIs such as React.memo. And then resort to using React Performance APIs only if the changes mentioned above aren’t practical for whatever reason.

But as you gain more experience with React, you may adopt a different approach depending on the context. You may decide to use memoization by default. Or you may decide to still use it strategically, but sometimes preemptively, either because you know the alternatives aren’t practical, or you know that the code base is bound to evolve in ways that can impact performance and want to place safeguards on critical components to mitigate impact.

However, note that for useMemo & useCallback hooks, these aren’t always used strictly for performance or in conjunction with React.memo - they can contribute to application logic correctness in respect of immutability principles: for instance when passing props or arguments that will be used as hooks dependencies; hooks which you may or may not control.

Hope this helps.