Skip to content
This repository has been archived by the owner on Feb 26, 2022. It is now read-only.

Component Principles

stephenp edited this page Jul 5, 2018 · 9 revisions

Enums over flags

If the option is going to be one or the other, don't allow both. Utilize enums when there are options instead of flags - if two things being true at the same time doesn't make sense, we shouldn't do it.

All callbacks start with on

This one doesn't really need an explanation.

Inherit classNames

Overrides on a per case basis are inevitable, so if a simple utility class on the element would do the trick we should make that easy (as opposed to adding a class to a wrapper and having to override with custom CSS).

Utilize {children} when possible

Composition is arguably components' strongest attribute. We should reach for this so that we can create more abstract, flexible, and composable components.

Render props over HOCs

If you need to pass functionality/scope from one component to another, do it with a render prop instead of higher order components. It's more explicit.

Render props over configuration

Instead of passing an array of objects to be rendered by the component, perhaps it makes more sense to pass the actual DOM elements to be rendered.

Boolean props default to false (name accordingly)

While this can seem weird, it's for compatibility. When adding something new, previous instances won't have that prop value set (undefined/falsey). Defaulting the value to false will mean that existing uses remain the same while adding new functionality.

React.PureComponent

While you can get away with a lot of UI elements being stateless functional components, the moment you need to tie into the React component lifecycle, or organizing blocks into methods...you end up having to rewrite the component structure anyway. To avoid this, I find it much more useful to just start by extending React.PureComponent from the start.

Clone this wiki locally