Weekly React Rundown

React and S.O.L.I.D. Principles: Building Robust Applications (Part 1)

A SOLID Approach to Engineering

7 min readFeb 10, 2024

A book with the React symbol as cover, followed by the title of this article bellow it.

1. Introduction

Welcome to the first piece of our exciting series, “React and S.O.L.I.D. Principles: Building Robust Applications.” In this journey, we’ll dive deep into software engineering by exploring how the S.O.L.I.D. principles, introduced by Robert C. Martin [1], can enhance your development skills and shield your application from rotting design symptoms.

This article will focus on React Function Components. If you’re new to React’s world or need a refresher, an excellent article about the subject can be found in [2].

Throughout these articles, we’ll explore those powerful principles by developing a Task Manager application from scratch! Each piece will present gradual improvements that can be downloaded from this repository.

2. Overview of S.O.L.I.D. Principles

Before we dive into the React world, let’s build our understanding of what the acronym S.O.L.I.D. stands for:

Single Responsibility Principle: A class (or component) should have only one reason to change.
Open/Closed Principle: Objects or entities should be open for extension but closed for modification.
Liskov Substitution Principle: Objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
Interface Segregation Principle: No client should be forced to depend on methods it does not use.
Dependency Inversion Principle: Depend upon abstractions, not concretions.

3. Why S.O.L.I.D. in React

At its heart, React is all about components! Think of them not just as the building blocks of a React app but as the secret ingredient that brings software engineering into play.

A bowl of cereal forming partialy the word SOLID.

The S.O.L.I.D. principles are guidelines that help developers produce efficient, maintainable, and scalable code. By adhering to these principles, developers can ensure that their code is easy to modify, test, and extend over time.

4. A Deep Dive Into The Basics for React

4.1. The Single Responsibility Principle (S.R.P.)

Let’s dive deep into the Single Responsibility Principle (S.R.P.). In React, S.R.P. means that a component should ideally do one thing and do it well. If you find your component doing too much, it’s probably time to break it down.

The S.R.P. principle provides a constructive approach to writing better code by separating different concerns. To implement this principle, we should focus on:

Identifying the various components that constitute our application.
Determining the most suitable location for each one of these components’ states.
Establishing what changes and when each state is altered.

By adopting this approach, we can ensure that our code is well-organized and easier to maintain.

4.2. The Open/Closed Principle (O.C.P.)

The Open/Closed Principle (O.C.P.) is like a wardrobe for your code: it’s all about adding new outfits (features) without stitching new patterns into your old clothes (modifying existing code). Imagine your software as a closet. With the O.C.P., you can hang new styles or seasonal additions without altering your favourite classic pieces. So, if your codebase was a coat, adding a scarf or a brooch for a fresh look is fair game, but you keep the coat’s original design untouched. It’s about keeping your codebase trendy and adaptable, ready for any season, without ever needing to unravel the seams of what’s already there.

5. Case Study: Applying S.R.P. and O.C.P. in a Task Manager React Application

Task Managers are often a go-to project for beginners embarking on software development. At first glance, they seem straightforward — a simple tool for tracking to-do items. However, what starts as a simple list can evolve into a sophisticated application by adding complex requirements such as task prioritization, categorization, deadlines, and notifications, to name a few.

This piece will implement two versions of the same application, one with a poor design and the other with a more educated approach. In the end, you can compare and contrast them and even make modifications for improvement. (Please leave comments below; I’m eager to see your creativity running wild!)

5.1. A Poor Component Hierarchy for a Task Manager App:

Imagine a React component that handles user inputs, performs calculations, and manages state changes in one component. The image below illustrates such an idea.

A poor react project architecture. Here the TaskManager component is the oly child of the App component.

src/
├── TaskManager/                  
│   ├── TaskManager.js            # Manages tasks, state, filters, logic, and UI
└── App.js

The application is primarily contained within a single TaskManager component alongside the App.js file in this first structure. This setup implies handling multiple responsibilities, including state management, U.I. rendering, and business logic. The critical points here are:

Centralization: Most of the application’s logic and state management is centralized within the TaskManager component.
Simplicity: A single component might seem more straightforward, especially for small projects.
Scalability Issues: As the application grows, this component can become increasingly complex and tougher to maintain.
Testing Challenges: Testing a component with multiple responsibilities can be more challenging, requiring more extensive test scenarios.

Such an approach can be downloaded from the repository here.

5.2. A Good Component Hierarchy for a Task Manager App:

A better structure, adhering to S.R.P. and O.C.P., would focus on breaking the previous application into manageable, focused, and specific tasks. This simplifies development, improves performance, and allows for easy modification

A better react project architecture. Here the TaskManager was broken into several smaller components which holds specific responsabilities.

src/
├── components/                   
│   ├── TaskList/
│   ├── TaskItem/
│   ├── TaskDialog/   
│   └── Header/
├── state/                        
│   ├── taskSlice.js              
├── hooks/                        
│   ├── useTasks.js               
├── utils/                        
│   └── taskUtils.js
└── App.js

The second structure showcases a modular approach, distributing responsibilities across dedicated directories and files. Components are broken (TaskList, TaskItem, TaskDialog, Header), with separate concerns for state management (taskSlice.js), custom hooks (useTasks.js), and utility functions (taskUtils.js). The important points here are:

Separation of Concerns: Each component and module is focused on a specific responsibility, making the codebase more understandable and maintainable.
Reusability: Components are designed to be reusable, which can reduce redundancy and improve consistency across the application.
Scalability: This structure is more scalable, as adding new features or components can be done easily without significantly impacting existing code.
Easier Testing: Testing is simplified as each component or module can be tested independently, focusing on its specific behaviour.

Such an approach can be downloaded from the repository here.

6. Best Practices and Common Pitfalls

6.1. Best Practices

Modular Design: Break down your React components into smaller, more manageable pieces that each serve a single purpose. This approach aligns with the Single Responsibility Principle, making your code more readable and accessible to debug.
Reusable Components: Aim to create reusable components across different parts of your application. This saves time and keeps your codebase DRY (Don’t Repeat Yourself).
Consistent Naming Conventions: Use clear and consistent naming for your components and functions. This practice is crucial for maintainability, especially when working in teams.
Testing: Write tests for your components. Unit tests ensure that each element correctly implements its intended functionality and adheres to your principles.
Documentation: Document your components well. Good documentation helps other developers understand your code, which is essential for collaborative projects.
Refactoring Regularly: Regularly revisit and refactor your code. This practice helps to continually align your codebase with S.O.L.I.D. principles as your application evolves.

6.2. Common Pitfalls

Over-Engineering: While applying S.O.L.I.D. principles, be cautious of over-engineering your components. Sometimes, simplicity is critical, and over-abstracting can lead to unnecessary complexity.
Ignoring Project Scope: Always consider the scope and scale of your project. A large-scale application might benefit more from strict adherence to S.O.L.I.D. principles than a small project.
Misunderstanding S.O.L.I.D. Concepts: Ensure you understand each principle before implementing it. Misapplying these principles can lead to more harm than good.
Resistance to Change: Avoid becoming too attached to your initial code. Be open to refactoring and changing your approach as you learn and grow as a developer.
Neglecting Performance: While focusing on design principles, don’t forget about the performance aspects of your application. Striking a balance between clean code and performance optimization is critical.

7. Conclusion

Today, we’ve just scratched the surface of integrating S.O.L.I.D. principles with React development. In wrapping up our exploration of the S.R.P. and O.C.P. within React projects, we’ve established that these principles are crucial for crafting applications that are easy to maintain, extend, and scale.

S.R.P. simplifies our components, focusing each on a single responsibility O.C.P., meanwhile, ensures our projects can grow and adapt effortlessly, allowing us to add new features like adding blocks to a LEGO set without needing to rebuild from scratch.

By integrating these principles, we’re not just coding; we’re building a foundation for software that’s robust, adaptable, and delightful to develop. They guide us towards better design decisions, making our applications resilient in the face of change and complexity.

Stay tuned for our next article from the series: React and S.O.L.I.D. Principles: Building Robust Applications.”

8. Preview of the Next Article: Levelling Up with Liskov & Friends

Get ready to elevate your React understanding in our next adventure, where we’ll be exploring uncharted territories with the Liskov Substitution Principle and its companions.

Expect cleaner code, sharper logic, and React components that not only do their job well but can be extended. We’ll unravel the mysteries of Liskov, Interface Segregation, and Dependency Inversion in a way that’s sure to make your React projects more modular, scalable, and, frankly, impressive. Don’t miss out, as we turn good code into great code. Stay tuned, and let’s continue to build better together.

9. Call to Action

I invite you to look at your current React components. Can you identify any opportunities for improvement? Would you be able to refactor by yourself the poor architecture? Leave your comments below!

Like what you see?