- Use wireframes as a visual aid for breaking UIs down into components
- Have a design system in place and stick to it strictly
- Involve the designer in creating a design system of components
- Use sane CSS architecture — CSS modules w/ BEVM combined w/ utility first CSS
- Order of the style import statements matters
- Favour local state and props over using a state container
- Avoid duplicating data, there must be a single source of truth for everything
- Favour immutable state over mutable state (for performance reasons)
- If you find yourself passing props down several levels, use state container
- Prop types for the win, tell React your data type expectations
- Avoid compound types in prop types, if a property can be a number or an object, something is clearly wrong with your data architecture
- Favour Containment over Specialisation to avoid tight coupling
- Separate components into container (less) and presentational (more) components
- Components should only have single responsibility
- Don’t follow don’t repeat yourself obsessively
- When rendering arrays, make sure to add in keys that uniquely identify items
- Favour smaller components over larger (for performance reasons during updates)
- Leverage portals where you need to fully detach a component subtree
- Avoid side effects and impure functions
- Avoid components folder bloat — organise by feature rather than the type
- Do not name components after a part of state they connect to neither the role they play in the app
- Do not name properties after the state that gets passed in
- Name it according to the usage within the component
- Be very consistent with using same patterns within a single codebase
- Use tools that’ll statically analyse the code and pinpoint potential problems