ReactSmallTips: Interface Segregation in React components

At some point in your career as a software developer you might start worrying about not just write a code that works, but a code that is readable, easy to understand, easy to maintain and scalable. In other words, a good quality code.

In order to achieve that, there are some guides like: patterns, paradigms and principles. Those guides were designed by real developers to solve well known real problems in programming. Among them, we have SOLID Principles.

SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (aka Uncle Bob).

The SOLID acronym stands for: Single-responsiblity Principle; Open-closed Principle; Liskov Substitution Principle; Interface Segregation Principle; Dependency Inversion Principle.

I’ve already written an article covering the Open-closed Principle in React. In this one we’re gonna cover the Interface Segregation Principle.

So, what Interface Segregation Principle (ISP from now on) is all about? The idea here is that..

Clients should not be forced to depend upon interfaces that they do not use.
Robert C. Martin (aka Uncle Bob).

Bringing that concept to the React world, we could say that..
components shouldn’t depend on props that they don’t use. And there are at least two scenarios which that could happen.

1. We have a component Page that renders a ProductList component which renders a ProductItem component for each product mapped in ProductList.

Page component

ProductList component

Let’s say in our Page component we have a toggle to highlight products that are rated with 5 stars.

So in that case, each ProductItem needs to know if the Page wants to highlight the product. But, between our Page component and our ProductItem component we have our ProductList component. We could pass a prop (shouldHighLight) like Page => ProductList => ProductItem. But that means ProductList would depend upon a prop that it doesn’ t use. This well known bad practice in React is commonly called props drilling.

So, how can we apply the ISP to solve this issue? Well, there are some options for that. We could use React Context API or even a State Management to share states across components, but there is a simpler way to fix this, which is the renderProps approach. In this approach we create sort of a shortcut between Page and ProductItem and pass the shouldHighLight prop directly from Page => ProductItem. The ProductList doesn’t need to know about the shouldHighLight prop, hense it will no longer depend upon a prop that it doesn’t use.

Refactored Page component

Refactored ProductList component

2. Now that we applied the ISP to solve that drilling props issue, there is another scenario, much simpler, that we can also apply ISP in React components. Let’s say our ProductItem wants to render a ProductImage. This one only need the image path from product, it doesn’t care about other properties the product might have, so it shouldn’t have to depend upon things that it doesn’t use.

You probably have already done this instinctively in your code, and yet you didn’t know you were applying the Interface Segregation Principle.

So that was the ISP (Interface Segregation Principle) in action with React components. Hope this post was helpful.

You can find the code on my Github.
Thanks a lot for reading this far.

Cheers!