Writing elegant React Components

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better.

— Michael Feathers

We spend a majority of time reading and tweaking existing code rather than writing fresh code. Code readability can directly effect the speed with which you can make changes to your existing components, especially in large projects. That’s why, one must always optimize for incremental development.

Here, I share a few tips and conventions that have worked well for us in writing scalable components in large React projects.

Keep it short, silly !

ES6/7 has greatly simplified the code we write as javascript developers, and using these language constructs in way that fit React patterns can make your components concise.

Use class properties for binding methods

Chances are, you’re already compiling your code with babel. Adding the stage-2 preset allows you to use class properties, that can provide an elegant way to bind this in non-lifecycle methods. This is also much cleaner than other alternatives.

Write short render functions

The render function is an entry point for your component. If the render function is growing in length even after extracting out components, consider using the ES7 getters to group together related JSX elements.

ES7 getters are lightweight, expressive and automatically bind this reference to the method.

Litmus test: Can you guess what the component renders in the time it takes to comprehend a haiku?

De-structuring and Whitespace

While not limited to react code, use of de-structuring avoids long and repetitive access chains and adds some breathing space to your component. Also, feel free to separate logical statements blocks with new lines.

Litmus test: Is your code minimal yet? … Now? … What about now?

Follow consistent naming conventions

Naming things right can be hard if you’re used to minifying code by hand. Otherwise, its just moderately tough. Intuitive naming can greatly reduce cognitive load for new developers (or the future you) and enhance code readability.

Naming your components idiomatically

A good component name is a one that conveys both visual and spacial significance of the component to it’s user.

1. For components that are customised native DOM elements or are basically native elements on steroids, utilize the native element name as suffix. eg. DangerButton, CountryDropdown.
2. For larger structural components, use suffixes like Card, Bar, List, Menu etc. to add spacial connotation to your component.
3. For Page level components, use a Page suffix.

Litmus test: Can you distinctly guess both — where in the page layout the component is being used, and what it looks like as soon as you see its name in your editor’s quick switcher?

Naming your props

Like component names, props are a part of the contract between the component and the user of a component. Prop names should be clear, concise and unambiguous.

1. Boolean Props can be made clear by naming them like — is<some-state> , should<show-some-behaviour>, or show<something>.
2. Props that represent event callbacks can be written like — on<eventSubject><eventType> . Usage of eventSubject is optional, but recommended when one needs to add some specificity.
3. Avoid using suffixes like list, data to prop names, since they are redundant and only add noise. e.g. <ProductGallery products={...} /> instead of <ProductGallery productList={...} />

Litmus test: Can you guess both — the data type and purpose of the prop with certainty without looking up it’s definition?

Naming your event handlers

Event handlers should be named in the same format as the event prop they are being passed to — handle<eventSubject><eventType>.

However, in this case, adding a eventSubject is usually required to disambiguate handlers with similar event types.

Litmus test: Can you guess both — the element the event handler belongs to, and when it fires — just by looking at the handler?

Order your methods

Component definitions can get long and have a dozen different methods. Keeping the methods organised into sorted groups will make navigating through code much easier. These logical groups can be:

1. Lifecycle Methods
2. Event Handlers
3. Helper functions
4. Getters and Setters

While eslint-plugin-react does have a sort-comp rule, it currently does not recognise ES7 getters. The sort-class-members plugin might be a better option therefore. There’s also a codemod I wrote that can automate the sorting process for you, so you don’t have to worry about rearranging stuff from time to time.

Litmus Test: Can you predict where in a component file the method may be defined without using Go To Definition in your editor?

This list of isn’t exhaustive by any means, and a lot of other things matter too. New suggestions always appreciated!