DEV Community: Ugo VENTURE

Part 4: Test-Driven Development (TDD) in React

Ugo VENTURE — Wed, 16 Oct 2024 10:00:00 +0000

Table of Content

Introduction
Core Principles of TDD
Setting Up a React Project for TDD
Writting Effective Tests for React Components
Common Pitfalls in TDD and How to Avoid Them
Conclusion

Introduction

What is TDD?

Test-Driven Development (TDD) is a software development methodology where tests are written before the actual code. It follows a short, repetitive cycle: first, a test is written that defines a desired functionality. The test is run, and since no code has been implemented yet, it fails. The developer then writes the simplest code possible to pass the test, runs the test again, and once it passes, the developer refactors the code to improve quality while keeping the tests green.

The goal of TDD is to lead development through clear specifications while ensuring that every line of code is covered by tests. It helps to catch defects early, ensures that the code is working as expected, and allows the developer to make changes without fear of breaking existing functionality.

Why Use TDD in React Development?

In React, TDD can significantly enhance the way we develop components, manage state, and interact with APIs. React applications are often composed of small, reusable components that handle specific user interactions or display data. TDD encourages us to define the expected behavior of these components before we implement them, ensuring that they meet requirements from the start.

Some specific benefits of TDD in React include:

Improved Component Design: Writing tests first forces us to think about how a component should behave before implementation, leading to cleaner, simpler designs.
Easier Refactoring: With a suite of tests in place, you can refactor your components or change the implementation without worrying about breaking other parts of your app.
Fewer Bugs: Writing tests ahead of time means that the code is constantly being validated, reducing the chance of bugs slipping through to production.
Documentation by Tests: Well-written tests serve as living documentation for your components, showing how they should behave in different scenarios.

Core Principles of TDD

The Three Laws of TDD (Kent Beck)

TDD is governed by three fundamental laws outlined by Kent Beck, which define how a developer should approach writing code:

You may not write production code unless it is to make a failing test pass.
This rule ensures that the focus remains on testing and that no code is written without a purpose. It guarantees that every piece of code is written with testing in mind, ensuring high-quality, functional software.
You may not write more of a test than is sufficient to fail.
Tests should be written incrementally. Write just enough code to fail, focusing on one requirement at a time. This keeps the testing cycle fast and lightweight, ensuring that the code grows only as much as necessary to fulfill the test.
You may not write more production code than is sufficient to pass the test.
Write the minimal code necessary to pass the test. This keeps the codebase lean and prevents overengineering. You can always improve the design later in the refactoring step.

These laws emphasize a disciplined and incremental approach to writing both tests and production code. In React, they help ensure that components are only as complex as they need to be and that their functionality is thoroughly validated.

Benefits of TDD

TDD offers several tangible benefits, particularly in the context of React development:

Confidence in Code: Each line of code is covered by tests, giving you confidence that your components work as expected and allowing you to make changes safely.
Maintainability: TDD encourages the development of small, focused components, making the overall system easier to maintain. Components developed under TDD tend to have cleaner interfaces and fewer side effects.
Improved Architecture: Writing tests first forces you to design components with testability in mind, leading to a better separation of concerns and higher cohesion in your code.
Faster Debugging and Refactoring: Tests act as a safety net, catching potential bugs early in development. Additionally, when refactoring, you can lean on tests to ensure that nothing breaks during the process.

Setting Up a React Project for TDD

Tools and Libraries

To effectively implement TDD in React, you need the right tools for writing and running tests. Here are the key tools that should be part of your setup:

Jest: Jest is a testing framework widely used in the React ecosystem. It offers a powerful and easy-to-use test runner, along with features like mocking, snapshots, and code coverage. Jest is often bundled with React projects, especially if you use create-react-app.
React Testing Library: This is a popular library for testing React components. Unlike other libraries that focus on implementation details, React Testing Library encourages testing from the perspective of the user. It simulates real interactions like clicks, input events, and form submissions, ensuring that your components work as expected when used in a real application.
Mocking Fetch: For components that interact with APIs, you’ll need to mock HTTP requests. You can use node-fetch or Jest’s built-in mocking capabilities to simulate fetch calls and handle asynchronous data flows in tests. This is especially useful for keeping your tests fast and isolated from actual network requests.
TypeScript: If you’re using TypeScript, integrating it into the testing environment can help catch type errors early. TDD works seamlessly with typed interfaces, allowing you to define the structure of components and data upfront.

Project Setup

Here’s how to set up a new React project for TDD, using create-react-app as the base:

Initialize a New React Project: Run the following command to create a new React app with TypeScript support:

npx create-react-app my-app --template typescript

Install Testing Libraries: You’ll want to add the necessary testing dependencies. If you’re using a custom setup (rather than create-react-app), install Jest and React Testing Library:

npm install --save-dev jest @testing-library/react @testing-library/jest-dom

The @testing-library/jest-dom package provides custom matchers like .toBeInTheDocument() to improve the readability and expressiveness of your tests.

Configure Jest: Jest typically works out of the box with React, especially if you’re using create-react-app . If not, you might need a configuration file ( jest.config.js ), like this:

module.exports = {
  testEnvironment: 'jsdom',
  transform: {
    '^.+\\.tsx?$': 'babel-jest',
  },
  moduleFileExtensions: ['js', 'jsx', 'ts', 'tsx'],
};

Test Folder Structure: It’s a good practice to colocate your test files next to the components they are testing. For example:

src/
  components/
    Button.tsx
    Button.test.tsx

This ensures that tests stay close to the code they cover, improving discoverability and maintainability.

Writing Your First Test

The core of TDD lies in the Red-Green-Refactor cycle. This cycle helps developers build their applications incrementally, ensuring that each feature or component is tested and works as expected before moving forward. Here’s how this cycle works in the context of React development:

Step 1: Red (Write a Failing Test)
The first step in TDD is to write a test that defines the desired behavior of the component. At this stage, no production code exists, and the test should fail because the functionality is not yet implemented. This is important because it ensures that the test is correctly checking for the required behavior.

For example, if you’re building a form component in React, you would start by writing a test to verify that the form renders an input field and a submit button, even though the form component does not exist yet.

// Form.test.tsx
import { render, screen } from '@testing-library/react';
import Form from './Form'; // The Form component does not exist yet

test('renders a form with an input and a submit button', () => {
  render(<Form />);
  expect(screen.getByPlaceholderText('Enter text')).toBeInTheDocument();
  expect(screen.getByRole('button', { name: /submit/i })).toBeInTheDocument();
});

When you run this test, it will fail because the Form component does not exist. This is the Red stage, indicating that we need to implement the missing functionality.

Step 2: Green (Write Minimal Code to Pass the Test)

Once the test is written and fails, the next step is to write the simplest possible code to make the test pass. The goal here is not to write the final version of the component but just enough to ensure that the test passes.

Here’s the minimum code required to pass the test for the form component:

// Form.tsx
import React from 'react';

const Form: React.FC = () => (
  <form>
    <input placeholder="Enter text" />
    <button type="submit">Submit</button>
  </form>
);

export default Form;

By adding a simple form with an input field and a submit button, we’ve now satisfied the test’s requirements. When you run the test again, it should pass:

PASS  src/components/Form.test.tsx
✓ renders a form with an input and a submit button (xx ms)

This is the Green phase, where the tests now pass, confirming that the functionality has been implemented.

Step 3: Refactor (Improve Code without Breaking Tests)

In the final stage, you can refactor your code to improve its structure, readability, or performance without changing its behavior. The tests act as a safety net, ensuring that your changes do not introduce any new bugs.

For example, if we wanted to extract the input and button into reusable components, we could refactor the Form component like this:

// InputField.tsx
import React from 'react';

interface InputFieldProps {
  placeholder: string;
}

const InputField: React.FC<InputFieldProps> = ({ placeholder }) => (
  <input placeholder={placeholder} />
);

export default InputField;

// SubmitButton.tsx
import React from 'react';

const SubmitButton: React.FC = () => (
  <button type="submit">Submit</button>
);

export default SubmitButton;

// Form.tsx
import React from 'react';
import InputField from './InputField';
import SubmitButton from './SubmitButton';

const Form: React.FC = () => (
  <form>
    <InputField placeholder="Enter text" />
    <SubmitButton />
  </form>
);

export default Form;

Even though we’ve made structural changes, the tests should still pass because the functionality remains the same.

Should Smaller Components Be Tested After Refactoring?

Yes, after refactoring your Form component into smaller components (like InputField and SubmitButton ), it’s important to test each of them individually. By testing smaller components, you ensure they adhere to the Single Responsibility Principle, making each component’s behavior more predictable and maintainable. Isolating tests for smaller components helps catch bugs early, prevents regressions, and simplifies debugging. Additionally, since React components are often reused in different contexts, having well-tested, modular components ensures they work correctly wherever they are integrated. Testing these smaller components provides confidence during future refactoring or feature enhancements.

Using TDD to Test Refactored Components

When applying TDD to refactored components like InputField and SubmitButton, the process remains the same: start by writing tests for each smaller component based on its expected behavior. For example, you might write a test that ensures the InputField component displays the correct placeholder or triggers a callback when a user types. After writing the failing test (Red), implement the component just enough to make the test pass (Green). Finally, refactor the code for clarity or optimization without altering the test outcome. This approach ensures that even after refactoring, each component is fully covered by tests, providing a solid foundation for future changes while maintaining a behavior-first focus in your development cycle.

The Benefits of Red-Green-Refactor in React

Incremental Development: You can build complex features step-by-step without rushing to write production code. Each test drives the development of the next part of the application.
Refactoring Confidence: With tests in place, you can refactor components without worrying about breaking existing functionality, leading to cleaner, more maintainable code.
Reduced Bugs: Since every piece of functionality is tested right from the start, there’s a much lower chance of bugs making their way into the codebase.
Better Design: Writing tests first encourages thinking about how to design components that are easier to test, leading to better separation of concerns and more modular code.

The Red-Green-Refactor cycle aligns perfectly with React’s component-based architecture, encouraging the creation of simple, testable components.

Writting Effective Test for React Components

Writing effective tests in React involves more than just following the TDD cycle. It’s essential to ensure that the tests are maintainable, meaningful, and provide the right kind of feedback. The goal is to write tests that focus on behavior rather than implementation, making your test suite robust, flexible, and easy to maintain over time.

Focus on Behavior, Not Implementation

One of the key principles when testing React components is to test behavior, not the internal details of the implementation. Testing behavior ensures that your tests remain useful even if the internal implementation of your component changes over time.

For example, when testing a button component, you should care about whether the button triggers the correct action when clicked—not about how the button is styled or structured internally. If the implementation changes but the behavior remains the same, your tests should not break.

Example:

// Good: Testing the behavior that matters
test('calls onClick when the button is clicked', () => {
  const handleClick = jest.fn();
  render(<Button label="Click me" onClick={handleClick} />);

  fireEvent.click(screen.getByText('Click me'));
  expect(handleClick).toHaveBeenCalledTimes(1);
});

This test focuses on user behavior (the button being clicked), which is more stable than testing internal details like how the button renders or which class names it uses.

Keep Tests Simple and Readable

Tests should be easy to read and understand at a glance. This means avoiding complex test setups or overly verbose assertions. Keeping tests simple makes them easier to maintain and reduces the cognitive load for developers working on the project.

For example, avoid mocking or stubbing excessively unless absolutely necessary. You want your tests to reflect real usage patterns as much as possible.

Example:

// Simple and readable test for rendering
test('renders a button with a label', () => {
  render(<Button label="Submit" />);
  expect(screen.getByText('Submit')).toBeInTheDocument();
});

This test is straightforward, making it easier to understand the component’s behavior.

Use React Testing Library’s Best Practices

React Testing Library (RTL) encourages writing tests from the perspective of the user rather than focusing on implementation details. Some of the best practices include:

Use screen to query elements: screen allows you to query elements globally, improving the readability of tests.
Use role-based queries: RTL provides queries like getByRole, which are preferred because they are more aligned with accessibility and real-world usage.

For example, instead of querying for a button by its text or ID, you can query it by its role:

// Good: Using role-based queries for better alignment with accessibility
test('renders a button', () => {
  render(<Button label="Submit" />);
  expect(screen.getByRole('button', { name: /submit/i })).toBeInTheDocument();
});

This improves the test’s robustness, especially if the button’s text or implementation changes slightly.

Testing User Interactions

In React, components often handle user interactions like clicks, form submissions, and input changes. Your tests should mimic these real-world interactions to ensure that components behave correctly.

For example, for an input field:

test('updates value when typing into the input field', () => {
  render(<InputField />);
  const input = screen.getByPlaceholderText('Enter your name');

  fireEvent.change(input, { target: { value: 'John' } });
  expect(input.value).toBe('John');
});

Here, we simulate a user typing into the input field and ensure that the component updates the state correctly.

Avoid Overly Mocking

While mocking is sometimes necessary (e.g., for network requests or complex third-party libraries), over-mocking can make tests brittle and hard to maintain. Focus on mocking only the parts that are not directly relevant to your test’s core behavior.

For example, if you have a component that fetches data from an API, mock the network request but don’t mock too much of the component’s internal state:

// Good: Only mock external dependencies like fetch
test('fetches and displays data', async () => {
  global.fetch = jest.fn(() =>
    Promise.resolve({
      json: () => Promise.resolve({ data: 'Hello, world!' }),
    })
  );

  render(<DataFetchingComponent />);

  expect(await screen.findByText('Hello, world!')).toBeInTheDocument();

  global.fetch.mockRestore();
});

By only mocking the fetch request and keeping the test focused on the component’s behavior, this test remains meaningful and flexible to changes in internal logic.

Write Tests for Edge Cases

A well-rounded test suite covers not only the happy path but also edge cases, such as error states or unexpected inputs. Ensure your tests consider scenarios where things might go wrong.

For example, testing error states in a form:

test('displays error when input is empty and form is submitted', () => {
  render(<Form />);

  fireEvent.submit(screen.getByRole('button', { name: /submit/i }));
  expect(screen.getByText('Input is required')).toBeInTheDocument();
});

This ensures that your component handles edge cases, improving overall robustness.

With these principles in mind, your tests will be clearer, easier to maintain, and focused on real-world behavior. Effective tests ensure that as your React components evolve, you can confidently refactor and add new features while maintaining a stable codebase.

Common Pitfalls in TDD and How to Avoid Them

While TDD is a powerful methodology, it’s not without its challenges. Understanding common pitfalls can help you navigate them effectively and improve your TDD practice in React development.

Writing Tests After the Implementation
One of the most significant pitfalls is writing tests after the implementation instead of before. This undermines the TDD process and often leads to incomplete or ineffective tests. To avoid this, commit to writing tests first for every new feature or component. Set a clear mindset that tests are part of the design process, not an afterthought.

Over-Engineering Tests
In an attempt to cover every edge case, developers may over-engineer their tests, leading to complex and brittle test suites. This often results in tests that are difficult to maintain and understand. To combat this, focus on writing clear, concise tests that cover essential behaviors rather than attempting to account for every possible scenario. Remember, not every edge case requires a dedicated test; sometimes, integration tests can provide sufficient coverage.

Ignoring Test Failures
When tests fail, it’s crucial to investigate the underlying cause promptly. Ignoring test failures can lead to a backlog of issues that become overwhelming and difficult to resolve. Establish a practice of treating test failures as immediate tasks. Fix them before moving on to new features, ensuring your test suite remains reliable and reflects the current state of your codebase.

Testing Implementation Details
Testing the internal implementation of components rather than their external behavior can lead to brittle tests. These tests often break when minor implementation details change, even if the overall functionality remains intact. Instead, focus on testing the component’s output and user interactions. This way, your tests will be more resilient to changes, providing valuable feedback on the component’s behavior.

Neglecting to Refactor Tests
Just as you refactor your code, it’s essential to refactor your tests. As the application evolves, tests may become outdated or irrelevant. Regularly review and refactor your test suite to ensure it remains clear, concise, and aligned with the current structure and behavior of your components. This practice will help keep your test suite maintainable and effective over time.

Underestimating the Importance of Mocking
Mocking is a powerful technique in TDD, especially when dealing with external dependencies or complex components. However, underestimating its importance can lead to tests that are either too reliant on the actual implementation or that fail to accurately represent the component’s behavior in isolation. Properly leverage mocking to create a controlled testing environment, ensuring that your tests focus on the component’s logic without being affected by external factors.

Conclusion: Embracing TDD in React Development

Incorporating Test-Driven Development (TDD) into your React workflow can significantly enhance the quality and maintainability of your code. By adopting a TDD approach, you ensure that your components are built with a clear understanding of their expected behavior from the outset. This not only leads to fewer bugs but also instills confidence when making changes or adding new features.

Throughout this article, we’ve explored the core principles of TDD, including the Red-Green-Refactor cycle and the importance of writing tests first. We discussed common pitfalls to avoid, such as writing tests after implementation or neglecting to test smaller components, and provided strategies to navigate these challenges effectively.

As you continue to develop in React, consider integrating TDD into your workflow. Start small, focus on one component at a time, and gradually expand your test coverage. The discipline of TDD can transform your development experience, leading to cleaner, more robust code and a more confident approach to building applications.

Part 3: Clean Architecture in React

Ugo VENTURE — Wed, 09 Oct 2024 10:00:00 +0000

Table of content

Component Layering
Business Logic and Reusable Services
Testability
SOLID Principles
Cross-Cutting Concerns
Directory Structure and Modularity
Interfacing with APIs
Evolutionary Architecture

In modern web development, scalability, maintainability and testability are essential. As React applications grow in size and complexity, applying architectural principles becomes crucial to keeping the codebase clean and manageable. This is where Clean Architecture comes into play.

Clean Architecture, a term coined by Robert C. Martin, encourages the separation of concerns and promotes the creation of systems that are easy to extend and evolve over time. Applying these principles in a React project leads to better component structure, easier testing, and more flexible business logic.

In this article, we will explore how Clean Architecture can be applied to a React project by focusing on key concepts like component layering, separation of business logic, reusable services, and the application of SOLID principles. We will also touch on important topics like testability, cross-cutting concerns, directory structure, and how interface with APIs effectively. Finally, we will discuss evolutionary architecture and how following theses practices ensures your React App can grow adapt to future changes without sacrificing code quality.

Component Layering

One of the core ideas behind Clean Architecture is the separation of concerns, and this starts with component layering. In React, components should be clearly divided between those that handle application logic (often referred to as smart or container components) and those focus on rendering UI (often called dumb or presentational components).

Smart vs Dumb Components

Smart components are responsible for fetching data, managing state, and handling side effects such as API calls, or interacting with local storage. They act as the bridge between the business logic and the UI.
Dumb components, on the other hand, are stateless and purely responsible for displaying the UI. They receive data through props and render it without making any assumptions about where the data comes from.

By applying this layered approach, we ensure that the components focusing on UI remain simple, reusable, and testable, while logic-heavy components are responsible for managing the application’s state and side effects.

Example:
Let's say we're building a product listing page. A smart component can handle the data fetching and state management, while dumb component renders the product list.

// ProductContainer.tsx - Smart Component
import { useFetchProducts } from './useFetchProducts';

const ProductContainer: React.FC = () => {
  const { data, loading, error } = useFetchProducts();

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return <ProductList products={data} />;
};

// ProductList.tsx - Dumb Component
interface Product {
  id: number;
  name: string;
}

interface ProductListProps {
  products: Product[];
}

const ProductList: React.FC<ProductListProps> = ({ products }) => (
  <ul>
    {products.map(product => (
      <ProductItem key={product.id} product={product} />
    ))}
  </ul>
);

// ProductItem.tsx - Dumb Component
interface ProductItemProps {
  product: Product;
}

const ProductItem: React.FC<ProductItemProps> = ({ product }) => (
  <li>{product.name}</li>
);

export default ProductContainer;

Benefits of Component Layering:

Simplicity: By separating logic and UI, each component focuses on a single concern.
Reusability: Presentational components can be reused across different parts of the application.
Testability: Smart components can be tested for their logic, and dumb components can be tested for their rendering.

By adopting this approach, we create a clean structure in React where the UI is decoupled from the underlying business logic. This makes our code easier to maintain and extend over time.

Business Logic and Reusable Services

In Clean Architecture, business logic should be decoupled from the UI. This separation ensures that your core application logic remains reusable, testable and independent of any specific UI framework. In React, it's common to use hooks and service layers to handle business logic separately from the components.

Separation of Concerns with Hooks and Services
React components should focus on rendering the UI, while business logic should be handled by hooks and service layers. Custom hooks can encapsulate reusable logic, like API calls, state management, and data transformation, while service functions can handle external concerns such as data fetching, authentication, and more.

By isolating this logic, your components become more declarative and easier to maintain, while your services can be reused across different parts of your application or even in different projects.

Example:
Let's look at how we can structure a service for fetching products and encapsulate that logic in a custom hook.

// productService.ts - Reusable Service
export interface Product {
  id: number;
  name: string;
}

export const fetchProducts = async (): Promise<Product[]> => {
  const response = await fetch('/api/products');
  if (!response.ok) {
    throw new Error('Failed to fetch products');
  }
  return response.json();
};

// useFetchProducts.ts - Business Logic Encapsulated in a Custom Hook
import { useState, useEffect } from 'react';
import { Product, fetchProducts } from './productService';

export const useFetchProducts = () => {
  const [data, setData] = useState<Product[]>([]);
  const [loading, setLoading] = useState<boolean>(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    const loadProducts = async () => {
      try {
        const products = await fetchProducts();
        setData(products);
      } catch (err) {
        setError(err as Error);
      } finally {
        setLoading(false);
      }
    };
    loadProducts();
  }, []);

  return { data, loading, error };
};

Benefits of Separating Business Logic:

Reusability: The logic for fetching products can be reused across different components or even projects.
Testability: By isolating business logic in a custom hook or service, we can test the logic independently of the UI.
Maintainability: Keeping components simple and focused on rendering makes them easier to reason about and maintain over time.

This structure ensures that React components remain focused on displaying the UI, while business logic lives in services and hooks that are easy to reuse and test in isolation.

Testability

One of the key principles of Clean Architecture is to make the codebase highly testable. In React applications, this can be achieved by designing components, hooks, and services in a way that allows for easy unit, integration, and end-to-end testing.

Testing Smart and Dumb Components

As we discussed in the component layering section, separating smart components (those responsible for logic) from dumb components (those responsible for UI) improves testability.

Dumb Components can be tested with snapshot tests or unit tests to ensure that they render correctly given a set of props.
Smart Components can be tested by mocking the business logic, ensuring that they handle different states like loading, error and success correctly.

Testing Business Logic in Isolation
By moving the business logic into services and hooks, you can make that logic easy to test in isolation. You can mock external dependencies like APIs and ensure that your logic handles different conditions such as API failures or empty data.

Example:
Let's write some unit tests for both the dumb component (ProductList) and the custom hook (useFetchProducts) using React Testing Library and Jest.

// ProductList.test.tsx - Testing Dumb Component
import { render, screen } from '@testing-library/react';
import { ProductList } from './ProductList';

const mockProducts = [
  { id: 1, name: 'Product 1' },
  { id: 2, name: 'Product 2' },
];

test('renders a list of products', () => {
  render(<ProductList products={mockProducts} />);
  expect(screen.getByText('Product 1')).toBeInTheDocument();
  expect(screen.getByText('Product 2')).toBeInTheDocument();
});

// useFetchProducts.test.tsx - Testing Business Logic in the Hook using renderHook
import { renderHook, waitFor } from '@testing-library/react';
import { useFetchProducts } from './useFetchProducts';
import { fetchProducts } from './productService';

jest.mock('./productService');

const mockProducts = [
  { id: 1, name: 'Product 1' },
  { id: 2, name: 'Product 2' },
];

test('fetches and returns products', async () => {
  (fetchProducts as jest.Mock).mockResolvedValueOnce(mockProducts);

  const { result } = renderHook(() => useFetchProducts());

  // Assert initial loading state
  expect(result.current.loading).toBe(true);

  // Await the loading state change and data
  await waitFor(() => expect(result.current.loading).toBe(false));
  expect(result.current.data).toEqual(mockProducts);
  expect(result.current.error).toBeNull();
});

test('handles API error', async () => {
  (fetchProducts as jest.Mock).mockRejectedValueOnce(new Error('API Error'));

  const { result } = renderHook(() => useFetchProducts());

  // Assert initial loading state
  expect(result.current.loading).toBe(true);

  // Await the loading state change and error
  await waitFor(() => expect(result.current.loading).toBe(false));
  expect(result.current.error?.message).toBe('API Error');
  expect(result.current.data).toEqual([]);
});

Benefits of Testability:

Confidence in Code: By testing components and business logic independently, we can ensure that our application behaves as expected without relying on manual testing.
Early Bug Detection: Automated tests help catch bugs early during development, reducing the cost and effort of fixing issues later.
Refactor-Friendly: With a solid test suite in place, refactoring becomes much safer since you can quickly validate that changes haven’t broken any existing functionality.

Testability is not only about writing tests but about designing your React application in a way that makes writing tests easier and more efficient. This involves structuring your code to be modular, isolating concerns, and using patterns that make the logic testable without the need for complex setups.

SOLID Principles

The SOLID principles, originally defined for object-oriented programming, are also highly applicable to React applications. By following these principles, you can create components, hooks, and services that are easy to maintain, extend, and test over time.

1. Single Responsibility Principle (SRP)
Each component, hook, or service should have only one reason to change. In a React application, this translates into making components focus on rendering the UI and delegating business logic to hooks or services.

Example:

// ProductList.tsx - Focused Only on Rendering
import React from 'react';
import { Product } from './productService';

interface ProductListProps {
  products: Product[];
}

export const ProductList: React.FC<ProductListProps> = ({ products }) => (
  <ul>
    {products.map((product) => (
      <li key={product.id}>{product.name}</li>
    ))}
  </ul>
);

In this example, the ProductList component is only responsible for rendering the products. The logic for fetching or managing products should reside in separate hooks or services, adhering to the Single Responsibility Principle.

2. Open/Closed Principle (OCP)
Components and services should be open for extension but closed for modification. This means you should be able to extend their functionality without modifying their existing code.

Example:

// productService.ts - Open for Extension by Adding Filters
export const fetchProductsByCategory = async (categoryId: number): Promise<Product[]> => {
  const response = await fetch(`/api/products?category=${categoryId}`);
  if (!response.ok) {
    throw new Error('Failed to fetch products');
  }
  return response.json();
};

Here, we extend the fetchProducts service by creating a new function fetchProductsByCategory without modifying the original fetchProducts logic. This keeps the original service intact and easily extendable.

3. Liskov Substitution Principle (LSP)

Components, hooks, or services should be replaceable with their base or parent classes/interfaces without breaking the application. In React, this can be applied by making sure components or hooks adhere to consistent contract interfaces.

Example:

// Product.tsx - Rendering Any Kind of Product Component
interface ProductProps {
  name: string;
}

export const Product: React.FC<ProductProps> = ({ name }) => (
  <div>{name}</div>
);

// DigitalProduct.tsx - A Specialized Product
interface DigitalProductProps extends ProductProps {
  fileSize: string;
}

export const DigitalProduct: React.FC<DigitalProductProps> = ({ name, fileSize }) => (
  <div>
    {name} - {fileSize}
  </div>
);

Here, DigitalProduct can replace Product in the UI without breaking the application because it adheres to the same interface as Product (inheriting from ProductProps). This ensures that it complies with the Liskov Substitution Principle.

4. Interface Segregation Principle (ISP)

Instead of forcing a large, complex interface on components or hooks, break down interfaces into smaller, more specific ones. This avoids components having to implement or handle unnecessary properties.

Example:

// Separate Specific Interfaces
interface BasicProduct {
  id: number;
  name: string;
}

interface DigitalProduct extends BasicProduct {
  fileSize: string;
}

interface PhysicalProduct extends BasicProduct {
  weight: string;
}

// ProductDetails.tsx - Only Handling What’s Necessary
const ProductDetails: React.FC<BasicProduct> = ({ id, name }) => (
  <div>
    Product ID: {id}, Name: {name}
  </div>
);

In this example, we’ve broken down the product interfaces to ensure components only deal with the specific data they need, adhering to the Interface Segregation Principle.

5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions. In React, this can be applied by injecting dependencies such as API services or state management into components via hooks or contexts, rather than hard-coding them.

Example:

// ProductContext.tsx - Providing Dependencies via Context
import React, { createContext, useContext } from 'react';
import { Product, fetchProducts } from './productService';

interface ProductContextType {
  products: Product[];
  fetchAll: () => void;
}

const ProductContext = createContext<ProductContextType | undefined>(undefined);

export const ProductProvider: React.FC = ({ children }) => {
  const [products, setProducts] = React.useState<Product[]>([]);

  const fetchAll = async () => {
    const data = await fetchProducts();
    setProducts(data);
  };

  return (
    <ProductContext.Provider value={{ products, fetchAll }}>
      {children}
    </ProductContext.Provider>
  );
};

// useProduct.ts - Hook for Accessing Context
export const useProduct = () => {
  const context = useContext(ProductContext);
  if (!context) {
    throw new Error('useProduct must be used within a ProductProvider');
  }
  return context;
};

In this example, ProductProvider provides the product data and fetching logic through a context. Components that consume this logic do not depend directly on the fetchProducts service but on the abstraction provided by the context, adhering to the Dependency Inversion Principle.

Conclusion on SOLID in React:

Applying SOLID principles in React leads to more maintainable and scalable applications. By following SRP, you can keep components focused and simple. OCP ensures your components and services are easily extendable. LSP and ISP allow for flexibility and better abstractions, while DIP promotes loose coupling and better separation of concerns.

Cross-Cutting Concerns

Cross-cutting concerns in software architecture refer to functionalities that affect multiple components in your system. These can include logging, error handling, caching, security, and more. In a React application, it’s essential to manage cross-cutting concerns in a way that promotes reusability, separation of concerns, and maintainability.

In React, cross-cutting concerns can be implemented using techniques like Context API, higher-order components (HOCs), render props, or custom hooks. Each of these patterns allows us to handle cross-cutting logic without scattering the same code across multiple components.

Example 1: Handling Cross-Cutting Concerns with Context API (Error Handling)

Let’s say you need to manage error handling consistently across your application. A good approach is to centralize the error handling using React’s Context API.

ErrorContext.tsx - Centralized Error Management

import React, { createContext, useState, useContext, ReactNode } from 'react';

interface ErrorContextType {
  error: string | null;
  setError: (message: string | null) => void;
}

const ErrorContext = createContext<ErrorContextType | undefined>(undefined);

export const ErrorProvider: React.FC<{ children: ReactNode }> = ({ children }) => {
  const [error, setError] = useState<string | null>(null);

  return (
    <ErrorContext.Provider value={{ error, setError }}>
      {children}
    </ErrorContext.Provider>
  );
};

export const useError = () => {
  const context = useContext(ErrorContext);
  if (!context) {
    throw new Error('useError must be used within an ErrorProvider');
  }
  return context;
};

Example of Usage in a Component:

// ProductComponent.tsx - Using Centralized Error Handling
import React, { useEffect } from 'react';
import { useFetchProducts } from './useFetchProducts';
import { useError } from './ErrorContext';

export const ProductComponent: React.FC = () => {
  const { data, error: fetchError } = useFetchProducts();
  const { setError } = useError();

  useEffect(() => {
    if (fetchError) {
      setError(fetchError.message);
    }
  }, [fetchError, setError]);

  return (
    <div>
      {data.map((product) => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
};

In this example:

We create an ErrorContext that provides a centralized place to manage application-wide error states.
The ProductComponent can leverage this context for setting errors when the useFetchProducts hook encounters an error.

Example 2: Using Custom Hooks for Cross-Cutting Concerns (Authentication)

Another common cross-cutting concern is managing authentication across your app. A custom hook can be used to handle user authentication and protect routes.

useAuth.tsx - Custom Hook for Authentication

import { useState } from 'react';

interface User {
  id: string;
  name: string;
}

export const useAuth = () => {
  const [user, setUser] = useState<User | null>(null);

  const login = (userId: string, userName: string) => {
    // Mock login logic
    setUser({ id: userId, name: userName });
  };

  const logout = () => {
    // Mock logout logic
    setUser(null);
  };

  return { user, login, logout };
};

AuthenticatedComponent.tsx - Protecting Routes

import React from 'react';
import { useAuth } from './useAuth';

export const AuthenticatedComponent: React.FC = () => {
  const { user, logout } = useAuth();

  if (!user) {
    return <div>Please log in to access this page.</div>;
  }

  return (
    <div>
      Welcome, {user.name}! <button onClick={logout}>Logout</button>
    </div>
  );
};

In this case:

The useAuth hook handles the login/logout logic and provides a way to check the current user.
The AuthenticatedComponent can use this hook to check if a user is authenticated and render content accordingly.

Cross-Cutting Concerns Recap

Cross-cutting concerns in React, such as error handling, authentication, logging, or caching, can be effectively handled using tools like Context API and custom hooks. By doing this, we maintain separation of concerns and promote reusable logic, reducing the need to duplicate these functionalities across multiple components.

Directory Structure and Modularity

A well-organized directory structure is essential for managing complexity in a React application, especially as it scales. By focusing on modularity, separation of concerns, and grouping related files logically, you can make your codebase easier to maintain, extend, and understand. There’s no one-size-fits-all solution, but certain best practices can help.

Key Principles for Structuring a React App

Feature-Based Structure: Organizing the app based on features, rather than types of files (components, hooks, services, etc.), helps to isolate functionalities and keeps all relevant code in one place.
Separation of Concerns: Keep concerns like UI components, business logic, and data fetching separated into their respective modules.
Scalability: Organize your app to handle future growth, ensuring that adding new features or functionality doesn’t lead to clutter or complexity.
Reusability: Group reusable logic and components in a way that encourages reusability across the app.

Let’s break down an example directory structure for a feature-based React application.

Example: Directory Structure

src/
│
├── components/
│   ├── common/          # Shared UI components (buttons, inputs, etc.)
│   ├── layout/          # Layout components (Header, Footer, etc.)
│   └── ProductList.tsx  # UI component specific to a feature
│
├── features/
│   ├── products/        # Feature-based directory for "products"
│   │   ├── components/  # Components specific to this feature
│   │   ├── hooks/       # Custom hooks related to products
│   │   ├── services/    # API services for product data fetching
│   │   └── ProductPage.tsx  # Page component for product feature
│   └── authentication/  # Feature-based directory for "authentication"
│       ├── components/
│       ├── hooks/
│       └── services/
│
├── hooks/               # Global custom hooks
│   └── useAuth.tsx      # Example of a reusable hook
│
├── services/            # Shared services like API or utility services
│   └── api.ts           # Generic API service with fetch logic
│
├── context/             # Global contexts
│   └── ErrorContext.tsx # Centralized error handling
│
└── App.tsx              # Root component

Directory Breakdown

components/: Contains reusable and global components that are not tied to any specific feature. This includes common components like buttons, inputs, layout components (e.g., headers and footers), and any shared UI.
features/: The core of the structure where each feature (e.g., products, authentication) has its own directory. Each feature contains its own components, hooks, services, and pages. This makes it easier to scale and modify individual features independently.
hooks/: A folder for global custom hooks that can be shared across the application. Hooks that are feature-specific would go inside the feature directories.
services/: Contains shared services like API logic, utility functions, or any shared data-fetching logic. Feature-specific services should be organized within their respective feature directories.
context/: A centralized place for React Contexts that manage global application state (e.g., error handling, authentication state, or theme).

Why Feature-Based Structure?

Modularity: By organizing your app around features, you keep everything related to a feature together. This makes it easy to reason about where to find and update code.
Encapsulation: Each feature is encapsulated within its own folder, promoting separation of concerns and reducing the likelihood of unintended side effects.
Scalability: As the app grows, you can add new features without modifying or cluttering existing ones.

Example: Product Feature Structure

To demonstrate the principle, here’s an example of how you could organize a feature like products.

src/
└── features/
    └── products/
        ├── components/
        │   └── ProductList.tsx      # List of products UI
        ├── hooks/
        │   └── useFetchProducts.tsx # Custom hook for product fetching
        ├── services/
        │   └── productService.ts    # Product-related API services
        └── ProductPage.tsx          # Main page component for products

Each feature contains:

Components: UI components related to the feature.
Hooks: Custom hooks that encapsulate logic related to the feature (e.g., fetching product data).
Services: Services for interacting with external APIs or managing business logic related to products.
Page Component: The main page for this feature, rendering the overall layout and structure of the feature.

Evolutionary Directory Structure

As your application evolves, so should your directory structure. An evolutionary architecture approach suggests that the structure you start with should be flexible enough to adapt to changes in requirements, features, and complexity.

Start Simple: If you’re building a small project, avoid over-structuring the app from the start. Begin with a simpler structure, but make sure it’s easy to refactor as the project scales.
Modular Growth: As new features are added, group related components, hooks, and services together to promote feature-based modularity.
Refactor Early and Often: As soon as you notice a pattern (e.g., multiple features needing similar logic), refactor common logic into shared modules (such as global hooks or services). Don’t hesitate to adjust the structure when it starts becoming harder to navigate or maintain.

Recap on Directory Structure and Modularity

A modular and well-structured directory keeps your React codebase maintainable and scalable as the application grows. By using a feature-based directory structure, you can encapsulate logic, promote separation of concerns, and ensure that individual features can evolve independently.

Interfacing with APIs

Interfacing with APIs is a fundamental aspect of modern web applications, especially in React. As applications become more complex and rely on external data, it’s crucial to manage API interactions effectively. This includes organizing API calls, handling responses, and managing error states in a way that keeps the application responsive and user-friendly.

Key Considerations for API Interfacing

Separation of Concerns: API logic should be separated from UI components. This makes it easier to manage, test, and reuse API calls without intertwining them with the presentation layer.
Consistent Error Handling: Ensure that errors from API calls are handled uniformly across the application to enhance user experience and debugging.
Data Transformation: Often, data received from APIs may need to be transformed into a format that your application can work with efficiently. Managing this transformation in a dedicated layer helps maintain clean code.
Caching and Optimizations: Depending on the app’s requirements, implementing caching strategies can significantly improve performance, especially for frequently accessed data.

Example: Structuring API Calls

We can manage API calls in a dedicated service layer. Let’s create a simple example for interfacing with a products API.
Product Service (productService.ts)

// src/features/products/services/productService.ts
const API_URL = 'https://api.example.com/products';

export const fetchProducts = async () => {
  const response = await fetch(API_URL);

  if (!response.ok) {
    throw new Error('Failed to fetch products');
  }

  const data = await response.json();
  return data; // Transform data if necessary
};

In this service:

We define a fetchProducts function that handles the API call to fetch product data.
The function throws an error if the response is not okay, promoting consistent error handling.

Using the Product Service in a Custom Hook (useFetchProducts.ts)

Now, let’s create a custom hook that uses the product service.

// src/features/products/hooks/useFetchProducts.ts
import { useEffect, useState } from 'react';
import { fetchProducts } from '../services/productService';

export const useFetchProducts = () => {
  const [data, setData] = useState([]);
  const [error, setError] = useState<string | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const loadProducts = async () => {
      try {
        const products = await fetchProducts();
        setData(products);
      } catch (error: any) {
        setError(error.message);
      } finally {
        setLoading(false);
      }
    };

    loadProducts();
  }, []);

  return { data, error, loading };
};

In this hook:

We manage the loading state and error state to give feedback to the user.
The fetchProducts service is called within a useEffect hook to fetch data when the component mounts.

Using the Custom Hook in a Component (ProductComponent.tsx)

Finally, we can use the custom hook in our component.

// src/features/products/components/ProductComponent.tsx
import React from 'react';
import { useFetchProducts } from '../hooks/useFetchProducts';

export const ProductComponent: React.FC = () => {
  const { data, error, loading } = useFetchProducts();

  if (loading) {
    return <div>Loading products...</div>;
  }

  if (error) {
    return <div>Error: {error}</div>;
  }

  return (
    <div>
      {data.map((product) => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
};

Best Practices for API Interfacing

Keep Services Isolated: By isolating API services from components, you promote reusability and maintainability.
Error Handling: Always handle errors gracefully and inform users about issues without crashing the app.
Transform Data: If you need to manipulate or transform the API data, consider doing so within the service or a separate function, maintaining separation of concerns.
Use HTTP Clients: Consider using libraries like Axios or Fetch API to simplify HTTP requests and improve error handling.
Caching Strategies: Implement caching mechanisms (like React Query) if your application fetches data frequently to enhance performance.

Recap on Interfacing with APIs

Organizing API interactions is crucial for building scalable and maintainable React applications. By structuring your API logic in a dedicated service layer, you promote separation of concerns and enhance the overall user experience through consistent error handling and loading states.

Conclusion

Clean architecture in React promotes maintainability, scalability, and adaptability. By focusing on component layering, reusable services, testability, SOLID principles, modularity, API interfacing, and evolutionary architecture, you can build robust applications that stand the test of time.

This article specifically addresses clean architecture within the context of React, providing practical examples and guidelines tailored to the librairie. However, I highly recommend reading Robert C. Martin’s book on clean architecture, as it delves deeper into the subject beyond specific libraries and frameworks. Martin’s insights are not only informative but also truly passionate, offering a broader understanding of architectural principles that can enhance your overall approach to software development.

By following these guidelines, you can ensure that your application remains manageable and easy to adapt as your project grows and changes.

Part 2: Clean Design in React

Ugo VENTURE — Wed, 02 Oct 2024 10:00:00 +0000

Clean design in React applications is essential for maintaining readability, reusability, and scalability. As applications grow in complexity, adhering to good design principles becomes crucial for developers. In this article, we will explore the significance of component composition, examine effective React design patterns, and delve into the power of declarative programming. By adopting these practices, developers can create applications that are not only functional but also elegant and easy to maintain.

Component Composition

Component composition is the cornerstone of building modular and reusable React applications. It allows developers to create complex UIs by combining smaller, simpler components, each with a specific purpose.

Example:

Consider a Button component

import React from 'react';

type ButtonProps = {
  children: React.ReactNode;
  onClick: () => void;
};

const Button: React.FC<ButtonProps> = ({ children, onClick }) => (
  <button onClick={onClick}>{children}</button>
);

Now, you can compose this button within different contexts:

const SubmitButton: React.FC = () => (
  <Button onClick={() => console.log('Submitted!')}>Submit</Button>
);

const CancelButton: React.FC = () => (
  <Button onClick={() => console.log('Cancelled!')}>Cancel</Button>
);

This approach reduces duplication and enhances readability. When you compose components, you create a clear hierarchy and a flow that mirrors the UI structure, making it easier to understand the relationships between different parts of your application.

React Design Patterns

When building React applications, design patterns play a crucial role in ensuring scalability, maintainability, and clean design. While there are many patterns used by developers to structure their React code, we won’t cover all of them in this article. Instead, we’ll focus on a few of the most commonly used and impactful patterns to get you started.

For a more comprehensive deep dive into all the React design patterns, stay tuned for a future article where I’ll cover the full range of patterns that can be applied in different scenarios.

Presentational and Container Components

This pattern separates the UI (presentational components) from the logic (container components). Presentational components are responsible for rendering UI, while container components handle state and business logic.

Example:

// Presentational Component
type UserListProps = {
  users: { id: number; name: string }[];
};

const UserList: React.FC<UserListProps> = ({ users }) => (
  <ul>
    {users.map(user => (
      <li key={user.id}>{user.name}</li>
    ))}
  </ul>
);

// Container Component
const UserContainer: React.FC = () => {
  const [users, setUsers] = React.useState<{ id: number; name: string }[]>([]);

  React.useEffect(() => {
    const fetchUsers = async () => {
      const response = await fetch('/api/users');
      const data = await response.json();
      setUsers(data);
    };

    fetchUsers();
  }, []);

  return <UserList users={users} />;
};

This separation promotes better maintainability and testing.

Higher-Order Components (HOCs)

HOCs are functions that take a component and return a new component, enhancing its functionality. They are useful for code reuse, such as adding authentication or data fetching capabilities.

Example:

import React from 'react';

const withUserData = <P extends object>(WrappedComponent: React.ComponentType<P>) => {
  return (props: Omit<P, 'user'>) => {
    const [user, setUser] = React.useState<{ id: number; name: string } | null>(null);

    React.useEffect(() => {
      const fetchUser = async () => {
        const response = await fetch('/api/user');
        const data = await response.json();
        setUser(data);
      };

      fetchUser();
    }, []);

    return <WrappedComponent user={user} {...(props as P)} />;
  };
};

// Usage
const UserProfile: React.FC<{ user: { id: number; name: string } | null }> = ({ user }) => {
  return <div>{user ? `Hello, ${user.name}` : 'Loading...'}</div>;
};

const EnhancedUserProfile = withUserData(UserProfile);

Render Props

This pattern allows sharing code between components using a prop that is a function. It enhances flexibility in rendering logic.

Example:

import React from 'react';

type DataFetcherProps = {
  render: (data: any) => React.ReactNode;
};

const DataFetcher: React.FC<DataFetcherProps> = ({ render }) => {
  const [data, setData] = React.useState<any>(null);

  React.useEffect(() => {
    const fetchData = async () => {
      const response = await fetch('/api/data');
      const result = await response.json();
      setData(result);
    };

    fetchData();
  }, []);

  return <>{render(data)}</>;
};

// Usage
<DataFetcher render={(data) => <DisplayComponent data={data} />} />;

Custom Hooks

Custom hooks allow you to encapsulate reusable logic in a function that can be shared across components, promoting cleaner and more organized code.

Example:

import { useState, useEffect } from 'react';

const useFetch = (url: string) => {
  const [data, setData] = useState<any>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch(url);
      const result = await response.json();
      setData(result);
      setLoading(false);
    };

    fetchData();
  }, [url]);

  return { data, loading };
};

// Usage in a component
const DataDisplay: React.FC = () => {
  const { data, loading } = useFetch('/api/data');

  if (loading) {
    return <div>Loading...</div>;
  }

  return <div>{JSON.stringify(data)}</div>;
};

Declarative Programming

Declarative programming focuses on what to achieve rather than how to achieve it. React embraces this paradigm by allowing developers to describe the UI in terms of its state rather than the steps to update the UI.

With React’s declarative nature, UI updates occur seamlessly as the state changes. This leads to less code, improved readability, and "fewer" bugs.

Example:

import React, { useState } from 'react';

const App: React.FC = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
};

In this example, React handles the DOM updates, allowing developers to focus on the application logic rather than manipulating the DOM directly.

Best Practices for Clean Design

To maintain clean design in React applications, consider the following best practices:

DRY (Don’t Repeat Yourself): Avoid code duplication by creating reusable components and hooks.
KISS (Keep It Simple, Stupid): Keep components focused and simple. If a component becomes too complex, consider breaking it down.
Type Safety: Use TypeScript to provide type safety and improve the developer experience.
Testing: Write tests for your components to ensure they behave as expected. This includes unit tests and integration tests.

Conclusion

Embracing clean design principles in React applications enhances maintainability, readability, and scalability. By focusing on component composition, utilizing effective design patterns, and leveraging declarative programming, developers can create robust applications that stand the test of time. Adopting these practices will lead to a more enjoyable and efficient development experience.

Part 1: Clean Code in React

Ugo VENTURE — Tue, 24 Sep 2024 20:29:31 +0000

Introduction to Clean Code in Frontend Development
Single Responsibility Principle (SRP) in React Components
Avoid Over-Rendering with Memoization
Clean Code Practices for Hooks
- 1. Separation of Concerns with Custom Hooks
- 2. Resusability: Creating Parameterized Custom Hooks
- 3. Avoid Side Effects in Return Values
- 4. Testing Custom Hooks

Introduction to Clean Code in Frontend Development

Clean code is a universal principle that transcends programming languages and paradigms, but in React, it holds particular importance due to the component-based architecture and declarative nature of the framework. React makes it easy to quickly create dynamic and interactive UIs, but without attention to clean code principles, your components can become bloated, hard to maintain, and prone to bugs.

This section focuses on how the principles of clean code, readability, simplicity and maintainability can be applied to React components. We will look at the Single Responsibility Principle (SRP), handling performance with memoization, and how to separate concerns using hooks. This will ensure that the code you write remains flexible and testable, improving overall quality of your React applications.

Single Responsibility Principle (SRP) in React Components

The Principle:
In object-oriented design, the Single Responsibility Principle (SRP) states that a class should have only one reason to change. In React, this principle applies to components: each component should ideally have one, clear responsibility. The component should focus on doing one thing well whether that's rendering UI, managing a small piece of state, or handling side effects.

Why SRP matters in React:

Readability: Components with a single responsibility are easier to read and understand. If a component does only one thing, it's much easier to reason about its behavior.
Testability: Smaller, focused components are eaasier to test in isolation. The more a component tries to do, the harder it becomes to cover all edge cases and behaviors in tests.
Reusability: When components focus on one thing, they are more likely to be reusable across different parts of the app.

Example - Refactoring a Bloated Component:

Let's start with a typical example where a component violates SRP by doing too much: handling state, rendering UI, and dealing with side effects like data fetching.

// BEFORE - Violates SRP
const UserProfile = ({ userId }) => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => {
        setUser(data);
        setLoading(false);
      });
  }, [userId]);

  if (loading) {
    return <div>Loading...</div>;
  }

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
};

This component is responsible for rendering the UI, fetching the data, and managing the loading state all of which could be separated.

Refactored Example Using SRP:

// Custom hook for fetching user data
const useUserData = (userId) => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => {
        setUser(data);
        setLoading(false);
      });
  }, [userId]);

  return { user, loading };
};

// UserProfile component focused on UI rendering
const UserProfile = ({ userId }) => {
  const { user, loading } = useUserData(userId);

  if (loading) {
    return <div>Loading...</div>;
  }

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
};

Explanation:
Here, the responsibility of data fetching is moved to a custom hook useUserData, while the UserProfile component only focuses on rendering the UI. This makes the component easier to understand, test, and reuse. The custom hook can now also be tested in isolation.

Avoid Over-Rendering with Memoization

The problem:
One of the most common performance pitfalls in React is unnecessary re-rendering. Every time a component re-renders, its children also re-render by default, even if their props haven't changed. This can lead to performance degradation, especially in large applications or components that perform expensive calculations.

Memoization in React:
React provides several tools to help prevent over-rendering:

React.memo: Prevents a functional component from re-rendering if its props have not changed.
useMemo: Caches a computed value to avoid recalculating it on every render.
useCallback: Memoizes a callback function so that it is not re-created on every render.

When to Use Memoization

Components that receive large or complex data via props.
Components that rely on expensive computations.
Callbacks passed to child components that might cause unnecessary re-renders.

Example - Preventing Over-Rendering using React.memo:
Let's start with an example of a component that could suffer from over-rendering:

const ItemList = ({ items }) => {
  return (
    <div>
      {items.map((item) => (
        <Item key={item.id} item={item} />
      ))}
    </div>
  );
};

If the parent of ItemList re-renders, even though the items array hasn't changed, each Item will still re-render.

Refactored Example using React.memo:

const Item = React.memo(({ item }) => {
  console.log("Rendering item:", item.name);
  return <div>{item.name}</div>;
});

const ItemList = ({ items }) => {
  return (
    <div>
      {items.map((item) => (
        <Item key={item.id} item={item} />
      ))}
    </div>
  );
};

Explanation:
By wrapping the Item component in React.memo, we ensure that it only re-renders if the item prop changes. This can be significantly improve performance, especially when rendering large lists or complex UI components.

Example - Avoiding Expensive Recalculations using useMemo:
Let’s say we have a component that computes a value based on a large dataset:

const ExpensiveComponent = ({ numbers }) => {
  const expensiveCalculation = (nums) => {
    console.log("Calculating...");
    return nums.reduce((acc, num) => acc + num, 0);
  };

  const total = expensiveCalculation(numbers);

  return <div>Total: {total}</div>;
};

In this case, every time ExpensiveComponent renders, the expensiveCalculation function runs even if the numbers array hasn't changed. This can quickly become inefficient in performance critical applications.

Refactored Example using useMemo:

const ExpensiveComponent = ({ numbers }) => {
  const expensiveCalculation = (nums) => {
    console.log("Calculating...");
    return nums.reduce((acc, num) => acc + num, 0);
  };

  const total = useMemo(() => expensiveCalculation(numbers), [numbers]);

  return <div>Total: {total}</div>;
};

Explanation:
In this refactored example, useMemo ensures that the expensiveCalculation function is only called when the numbers array changes. If numbers stays the same, the previously computed result is returned, avoiding the cost of re-running the calculation on every render.

Example - Avoiding Unnecessary Re-Creation of Functions using useCallback:

Let's say we have a Button component that accepts an onClick handler:

const ParentComponent = () => {
  const handleClick = () => {
    console.log("Button clicked");
  };

  return <Button onClick={handleClick} />;
};

In this example, every time ParentComponent re-renders, the handleClick function gets recreated, which will force the Button component to re-render, even though the function behavior is the same.

Refactored Example using useCallback:

const ParentComponent = () => {
  const handleClick = useCallback(() => {
    console.log("Button clicked");
  }, []);

  return <Button onClick={handleClick} />;
};

Explanation:
With useCallback, the handleClick function is memoized and will only be re-created if its dependencies (none in this case) change. This prevents unnecessary re-renders of the Button component since the reference to the onClick function remains stable.

Recap of Memoization Techniques

React.memo: Wraps a component and prevents re-rendering unless its props change.
useMemo: Memoizes a computed value, avoiding expensive recalculations on every render.
useCallback: Memoizes a callback function to prevent it from being recreated unnecessarily.

Clean Code Practices for Hooks

React's hooks API, introduced in React 16.8, revolutionized how developers manage state and side effects within function components. However, hooks can easily become a dumping ground for logic, leading to unmaintainable code if not used carefully.

This section will cover how to structure and encapsulate hooks, keeping them clean, readable, and testable.

1. Separation of Concerns with Custom Hooks

The Problem:
One of the most common anti-patterns in React is overloading components with both UI and logic responsibilities. When a component is responsible for rendering UI and managing complex state or side effects, it quickly becomes difficult to maintain, test, or extend.

Solution:
Custom hooks allow you to extract the logic from components and encapsulate it within reusable, isolated functions. This keeps your components clean and focused solely on rendering.

Example - Before Extracting a Custom Hook:
Let's look at an example of a component that handles both data fetching and UI rendering:

const UserList = () => {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    fetch("/api/users")
      .then((res) => res.json())
      .then((data) => {
        setUsers(data);
        setLoading(false);
      })
      .catch((err) => {
        setError(err);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error loading users</div>;

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

This component handles fetching data, managing loading and error states and rendering the UI. While not overly complex, the code becomes harder to manage as the logic grows.

Refactored Example using a Custom Hook

// Custom hook for fetching data
const useUsers = () => {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    fetch("/api/users")
      .then((res) => res.json())
      .then((data) => {
        setUsers(data);
        setLoading(false);
      })
      .catch((err) => {
        setError(err);
        setLoading(false);
      });
  }, []);

  return { users, loading, error };
};

// Component focused solely on rendering
const UserList = () => {
  const { users, loading, error } = useUsers();

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error loading users</div>;

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

Explanation:
Th useUsers hook encapsulates the data-fetching logic and manages state. The UserList component is now concerned only with rendering the UI based on the current state. This separation of concerns improves readability and testability and promotes reuse across different components.

2. Resusability: Creating Parameterized Custom Hooks

When creating custom hooks, aim for reusability by parameterizing them, so they work with different data or inputs. This follows the DRY (Don't Repeat Yourself) principle by avoiding duplicating similar logic accross different parts of your app.

Example - Parameterized Custom Hook for Data Fetching:
Let's extend the previous useUsers hook to be more generic, so it can fetch any resource by URL.

const useFetch = (url) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    fetch(url)
      .then((res) => res.json())
      .then((data) => {
        setData(data);
        setLoading(false);
      })
      .catch((err) => {
        setError(err);
        setLoading(false);
      });
  }, [url]);

  return { data, loading, error };
};

// Using the parameterized hook
const UserList = () => {
  const { data: users, loading, error } = useFetch("/api/users");

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error loading users</div>;

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

const ProductList = () => {
  const { data: products, loading, error } = useFetch("/api/products");

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error loading products</div>;

  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
};

Explanation:
By parameterizing the useFetch hook, we've turned it into a reusable piece of logic that can be used in different components (UserList and ProductList). This reduces code duplication and keeps the app architecture cleaner.

3. Avoid Side Effects in Return Values

Custom hooks should not introduce side effects (such as triggering network requests or interacting with the DOM) in their return values. This make the look predictable and testable. Always isolate side effects inside the useEffect hook, keeping the return values pure.

Anti-Pattern - Triggering Side Effects in Return Values:

const useWindowSize = () => {
  let size = { width: window.innerWidth, height: window.innerHeight };

  window.addEventListener("resize", () => {
    size = { width: window.innerWidth, height: window.innerHeight };
  });

  return size;
};

This example causes a side effect (addEventListener) to occur directly when the useWindowSize hook is called, which is problematic as it's not well-contained and can lead to memory leaks or unpredictable behavior.

Correct Pattern:

const useWindowSize = () => {
  const [size, setSize] = useState({
    width: window.innerWidth,
    height: window.innerHeight,
  });

  useEffect(() => {
    const handleResize = () => {
      setSize({ width: window.innerWidth, height: window.innerHeight });
    };

    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return size;
};

Explanation:
The useWindowSize hook now keeps the side effects (adding and removing event listeners) inside the useEffect hook, while the return value remains pure. This makes the hook easier to reason about and test, while avoiding potential memory leaks.

4. Testing Custom Hooks

Ensuring your custom hooks are testable is crucial to maintain clean code. Hooks like useState and useEffect can complicate testing, but libraries like @testing-library/react-hooks make this straightforward.

Example - Testing a Custom Hook:

Here's how you can write a test for a custom hook like useFetch using @testing-library/react-hooks:

import { renderHook, act } from "@testing-library/react-hooks";
import { useFetch } from "./useFetch";

test("should fetch data correctly", async () => {
  global.fetch = jest.fn(() =>
    Promise.resolve({
      json: () => Promise.resolve([{ id: 1, name: "John Doe" }]),
    })
  );

  const { result, waitForNextUpdate } = renderHook(() => useFetch("/api/users"));

  // Assert that it's loading initially
  expect(result.current.loading).toBe(true);

  // Wait for the hook to finish fetching data
  await waitForNextUpdate();

  // Assert that it fetched the data correctly
  expect(result.current.data).toEqual([{ id: 1, name: "John Doe" }]);
  expect(result.current.loading).toBe(false);
});

Explanation:
This test verifies that the useFetch hook behaves correctly: it starts with a loading state, fetches the data, and updates the state accordingly. It uses @testing-library/react-hooks to render the hook in isolation, making the hook itself easy to test.

Key Takeways

Custom Hooks: Encapsulate logic inside custom hooks to maintain separation of concerns.
Reusability: Parameterize custom hooks to reduce duplication and maximize reusability.
Avoid Side Effects in Return Values: Isolate side effects within useEffect and keep return values pure.
Testability: Ensure custom hooks are testable in isolation using appropriate tools like @testing-library/react-hooks.

Conclusion:

Hooks are like the Swiss Army knives of React—versatile, powerful, and a little too easy to misuse if you're not careful! By crafting custom hooks, you're essentially sharpening your blade and keeping your components from getting bogged down in messy logic. When you avoid side effects in return values, you're ensuring things stay nice and predictable—no surprise explosions! And don't forget the golden rule: make those hooks reusable, because no one likes reinventing the wheel. Finally, make sure to test your hooks in isolation. After all, what's the point of all this magic if we can’t prove it works? Keep it clean, keep it sharp, and may your components live long and re-render less!

DEV Community: Ugo VENTURE

Part 4: Test-Driven Development (TDD) in React

Table of Content

Introduction

Core Principles of TDD

Setting Up a React Project for TDD

Writting Effective Test for React Components

Common Pitfalls in TDD and How to Avoid Them

Conclusion: Embracing TDD in React Development

Part 3: Clean Architecture in React

Table of content

Component Layering

Business Logic and Reusable Services

Testability

SOLID Principles

Cross-Cutting Concerns

Directory Structure and Modularity

Interfacing with APIs

Conclusion

Part 2: Clean Design in React

Table of Contents:

Component Composition

React Design Patterns

Declarative Programming

Best Practices for Clean Design

Conclusion

Part 1: Clean Code in React

Table of Contents

Introduction to Clean Code in Frontend Development

Single Responsibility Principle (SRP) in React Components

Avoid Over-Rendering with Memoization

Clean Code Practices for Hooks

1. Separation of Concerns with Custom Hooks

2. Resusability: Creating Parameterized Custom Hooks

3. Avoid Side Effects in Return Values

4. Testing Custom Hooks