While building React apps, one thing that really helps keep the code clean and easy to manage is following good design principles. One of the most important ones is the single responsibility principle. It basically means that a component should do just one thing and do it well.
In this blog, I’ll walk through how I applied this principle while working on a template rendering feature. The feature was complex, with nested structures like templates, components, sections, tables, and key-value pairs. Breaking it down using the single responsibility pattern made the whole thing much easier to manage.
As the name says, the single responsibility pattern is about making sure a React component does one thing only. When building components, we take care that each one is focused on a single purpose.
Let’s understand this with an example from a template rendering feature I worked on. In this feature, the frontend renders a complete template based on the data sent by the backend. The whole structure highly depends on how the backend sends the data.
A template here is a combination of headers and components (not React components). Each component can have multiple sections, and each section can either be a table or a key-value pair. Now let’s see how I applied the single responsibility principle in this setup.
This is the initial component that puts together the higher-level parts of the template — headers and components.
In TemplateDisplay, I’m only responsible for showing the template’s header and the list of components it contains. I don’t deal with how each component or section works. I simply pass the data to the next component. That’s the key here — this component’s only job is to arrange the layout of the top-level elements.
The responsibility here is to put together the sections inside a component — not how each section works.
In ComponentDisplay, a component might come with its own CSS or styling. It contains multiple sections, so this component’s job is to apply the component-level styles and then map over the sections and render the appropriate section component. Again, it doesn't handle the implementation of each section — just organizes them.
This is where the nesting of our template ends. Each section in the template can be of only two types — either a table or a key-value pair.