Skip to content

Instantly share code, notes, and snippets.

@christianalfoni
Last active February 13, 2019 13:32
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save christianalfoni/6e677cdd6db6615cd1b7936d6ecdfefd to your computer and use it in GitHub Desktop.
Save christianalfoni/6e677cdd6db6615cd1b7936d6ecdfefd to your computer and use it in GitHub Desktop.
Dan Abramov article proposal

The APIs React.PureComponent and React.memo are used to optimize performance of React. From the documentation:

If your React component’s render() function renders the same result given the same props and state, you can use React.PureComponent for a performance boost in some cases.

Questions I hope would inspire to write another technical article on React, focusing on these APIs and performance:

  1. I thought React always renders based on its props and state. What other reasons would make comparison break the behaviour of a component?

  2. "for performance boost in some cases"... what are these cases? Would really like scenarios and technical explanations of why it is faster, just like you explained for example "keys" in the previous article

  3. What are scenarios where using PureComponent and memo causes worse performance?

  4. What factors helps you evaluate when a PureComponent or memo is needed? The position in the hierarchy? The number of nested components? The number of props? How often the props change?

  5. Memoization is a concept not required in for example Vue, due to its reactive values. How do you evaluate overhead vs developer experience? Is the overhead of having all components doing shallow check, to remove the concept of memoization from the developer, such an overhead that developer experience does not even matter? Or is it considered that it would just cause a worse developer experience? If so... why?

  6. Do you consider the profiler to be an essential tool to figure out when and where to do these optimizations. If so, how does the profiler indicate this?

  7. I work on a project now where performance has been a big concern during development, as React noticebly causes janks. But when we deployed a production version all of this was gone. How does one evaluate performance when working on the development mode vs how it is actually experienced in production?

  8. With state management solutions you can drastically reduce the number of props passed through components. If most components has no props, but uses internal state, context or other observable like APIs. Would that change anything in terms of the overhead being non-existant, as most components has no props?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment