Refactoring React is a series documenting some of the things I've learned about how to write React and make the lives of future developers (or you a week from now) a little easier.

The first thing I look at in an unfamiliar React component is the return. I want to understand what the expected output is before I start reasoning about the rest. Ideally, the return is a nice block of JSX with some JS variables here and there. It's easy to read, and easy to track down variables or methods to figure out how the component works.

What I hope not to see is nested blocks of JS mapping, filtering, and anonymous-function-passing all over the place. Sights like this are not uncommon:

The thought process of reading that return goes something like:

 component... that has some... wait no it's conditionally returning the 

 children... that it's getting from a helper method? I'll dig into that later. Oh wait, it's filtering the children, too...

It's not pretty. All of the component's logic is mixed up with all of the component's JSX, and it's hard to reason about either.

Here's the same component with a basic refactor:

, which we pass a click handler to. It's easy to look up the variable and method above the return, and we can reason about the business logic and the output without getting dizzy.

Here are some of my rules of thumb for cleaning up 

Construct arrays before the return. Even a simple 

Conditional with caution. Having a focused ternary or logical && operator is great when you're toggling a component on or off. Once you start getting multiple conditionals, or conditionals with long blocks of JSX, consider pulling them out of the return by constructing them in a variable. Complex conditional logic can also be a sign it's time to create a new component.

Avoid passing anonymous functions. JSX isn't the first place anyone goes looking for function definitions, and they're impossible to reuse, hard to test, hard to debug, and can cause unnecessary renders.

Get outta here with that logic

Refactoring React - Cleaning up return() 

I've been doing a lot of React refactoring lately. I've seen some things.

Refactoring React is a series documenting some of the things I've learned about how to write React and make the lives of future developers (or you a week from now) a little easier.

Component composition is one of React's most powerful features. In my experience, however, it's often underutilized and misunderstood. As a React project becomes more complex, it's important to create reusable and composable components.

Component composition is the ability to combine React components to build other components. A good composable component encapsulates UI, logic, or both in a way that's easy to reuse. Something like a repeated stylistic element is the perfect thing to encapsulate.

Here's a simple react component that renders a 

 looks like a 'card' with rounded corners and a drop shadow.

Note: I'm totally glossing over the CSS here for the sake of clarity - more on that later

The project has many components that have the same card UI, but every component re-implements the 

 and the styles to create the card. Some developers may have implemented it differently, or a designer may have set the wrong border-radius in a comp. 

Having multiple implementations of the same thing is error-prone and inefficient. It also creates a lot of work if the design or business logic in the component ever changes.

This is the perfect low-hanging refactoring fruit to put component composition to use, so let's make a reusable 

 prop. It's a special prop that includes all the JSX nested inside our component. It lets us put other components inside our card component, just like you'd put elements inside a 

 to use in our original component we get:

 component, we can extend it with helpful features. If the client asks for a new component with an outlined card, it's easy to add.

, we'll get a card with an outline. Every place we've used 

 will also have access to this extra functionality.

Be careful when extending or editing common components! Changing a component's default behavior will change or break things elsewhere.


If you don't intend to change things globally, it's critical to cover the component with tests. For something simple that just returns DOM elements like our card example, 

 may do the trick. If there's business logic, make sure it's unit tested.


Also: if you find yourself doing lots lots of string stuff to construct 

Another important use of component composition is abstraction. Let's say we want to add a description list to our card. We get a list of product features from an API, and we want to sort that list based on user input.

Adding those features to our component might look something like this:

Notice how we sort features and construct the list outside of 

We just about doubled the number of lines in our component with our description list logic. While it works fine, we can improve things by pulling out the description list into its own component.

 component for the sake of clarity here. We could skip the prop destructuring and prop drilling by spreading props into 

 component has several benefits. First, we've moved logic specific to the feature list into a separate component. A new developer can look at 

 and make sense of it without having to understand how the list is being constructed.

We've also created a reusable component that we can use elsewhere on the site. We don't have to solve the list sorting and fragment constructing all over again.

Finally, it's easier to write and maintain tests for 

 when they're separate components. In a real project, 

 could contain several additional complex sections like the feature list. Testing all the logic and the DOM output in one place gets messy.

It's preferable to let composable components fill the space of their container. Setting a specific width, height, margin, or padding in a reusable component may fit your specific need, but doing so limits its reusability. You can handle layout in the parent component, or you could pass a class name as a prop that will apply specific layout properties.

I like to think of my components as mini responsive pages. They should be able to adapt to whatever container I put them in.

Some React component libraries further abstract layout into specific 'layout components'. The 

This may not apply to things like buttons, icons, and other elements that don't usually respond to the size of their container. They often have specific sizes - go ahead and set them.

KIVI DID

Refactoring React - Cleaning up return()

Get outta here with that logic

Refactoring React - Component Composition and Reuse

Keeping components simple and focused