Comprehensive List of React Best PracticesSep 27, 2019 · 4 minutes
In this article, I have collected comprehensive list of React JS best practices. Some of them are from react offical guide and other are from various sources in the internet. Let me know if I have missed something via comment.
Best practices for React Official Docs
- Props must be read only.
- Resources taken by any other resources should br free up when they are destroyed.
- Do not modify state directly. Use function to modify them.
- Neither parent nor child components should know if a certain component is stateful or stateless, and whether a function or a class.
- Bind the function in constructor to avoid
- React events are named using camelCase, rather than lowercase.
- For a component to hide itself return null from render
- Key is a required string attribute when creating lists of elements
- Elements generated inside a map() call need key
- Keys within arrays should be unique among their siblings
- When several components reflect the same changing data lift shared state up to a common ancestor
- Instead of writing shouldComponentUpdate() inherit from React.PureComponent where possible
- Avoid in-place mutation by using Object.assign, spread operator (…), and non-mutating operations
- You can use Immutable.js, seamless-immutable, or immutability-helper.
- Keys should be stable, predictable, and unique.
- Majority of applications do not need to use context.
- If you want your application to be stable, don’t use context.
- If you aren’t familiar with state management libraries like Redux or MobX, don’t use context.
Refs and Dom
- Typical React dataflow, props are the only way that parent components interact with their children.
- Refs are for a few cases to imperatively modify a child outside of the typical dataflow.
- When should we use ref:
- Managing focus, text selection, or media playback.
- Triggering imperative animations.
- Integrating with third-party DOM libraries.
Higher Order Components:
- Use HOC for cross cuttings concerns.
- A HOC compose the original component by wrapping it in the container component.
- Do not mutate the original component. We should use composition instead.
- Pass unrelated props through to the wrapped component.
- Warp the display name for easy debugging.
- Apply HOCs outside the component definition so that the resulting component is created only once.
- Be aware that refs aren’t passed through. Might end up unexpected behaviors.
- Render props are alternative to HOCs for cross-cutting concerns
- Render props enabling shared state or behavior between components.
- Higher order components cab be implemented with the render props.
- Prefer instance methods to avoid triggering extra redraws.
- We can limit the rate at which callback is executed via throttling and denouncing.
Presentational and Container Component:
It is generally recommended to separate component into presentational or container components. Here are the best practice guide for both types of components.
- Concerned with how thing look.
- Allow containments via
- Often have styles.
- Have no dependencies on rest of approach.
- Don’t specify how data is loaded or mutated.
- Receive data and callback exclusively via props.
- Rarely have their own state.
- Concerned with how thing will work.
- Usually don;t have any DOM markup of their own.
- Provide data and behavior to presentational or other container components.
- Are often stateful.
Because functional components are easier to understand, use them unless you need state, lifecycle hooks, or performance optimizations
Best Practices From Other Sources
Here are the list of best practices from other sources which I find useful.
- Prefer functional components over class based
- Prefer state initialization in class member variable declaration over constructor
- Pass functions to setState()
- Avoid passing closures to sub-components
- Use named functions to facilitate debugging
- Use short circuit evaluation when rendering on only one side of a condition
- Minimize nested ternary conditional expressions
- Breaking components up into containers and presentation.
- Always define a defaultProps.
- 10 Omit value when it is explicitly true
- Use many small components
- Render lists in dedicated components
- Don’t use array indexes as keys
- Bind functions early
- Normalize relationships in entity tree
- Log errors with Raven
- avoid nested state
- Keep things immutable
- Centralize state
- Thinner reducers
- Put logic in action creators
- Consider using Saga
- Use stateless components as much as possible
- Import the functions you need, not entire modules
- Bind functions in constructor
- Keep state as minimal as possible
- Respect the single source of truth when managing state