Forem: Nisal Tharaka

Compound Component pattern in react

Nisal Tharaka — Tue, 07 Jan 2025 07:12:25 +0000

Let’s think about a product component.

The code for the above component, without worrying too much about styles, will look like this.

// represents a product
type Item = {
  image: string;
  name: string;
  color: string;
  price: string;
};

const ProductCard = (product : Item) => {
  <View>
    <Image src={product.image} />
    <Text>{product.name}</Text>
    <Text>{product.color}</Text>
    <Text>{product.price}</Text>
  </View>
}

The ProductCard component has an Image and three Texts, wrapped in a View. The styles are left out for simplicity.

Imagine you need to show this Product in different places with some UI tweaks. For instance, if it’s in a favorites list, only the image and name should show up, or if it’s on a poster, show the image, name, and price.

To be more clear,

In a store page:	In a favorites list	In a poster

Image, Name, Color and price are visible	Only Image and Name are visible	Image, Name and Price are visible

To accomplish this, there are a few options:

You can create separate components for each page, but this will lead to code duplication and violate the DRY principle.
Alternatively, you can pass props and use them to manage visibility, for instance,

type ProductCardProps = {
  product: Item;
  isInStore: boolean;
  isInPost: boolean;
  isInFavorites: boolean;
};

const ProductCard = ({
  product,
  isInStore,
  isInPost,
  isInFavorites,
}: ProductCardProps) => {
  <View>
    <Image src={product.image} />
    <Text>{product.name}</Text>
    {isInStore && <Text>{product.color}</Text>}
    {!isInFavorites && (isInStore || isInPost) && <Text>{product.price}</Text>}
  </View>;
};

In this code, the color and price of a product will be shown based on some rules. If the isInStore prop is true, the color will be shown. If isInFavorites is false, and either isInStore or isInPoster is true, the price will be shown.

With all these condition props and how it’s being rendered, the ProductCard component becomes hard to read and goes against the SRP principle because it now responsible for controlling the visibility/rendering of its sub components. It also goes against the Open-Closed principle because the rendering logic will need to be changed if we want to make changes to the component in the future.

Better solution?

While the above options are great for small components that you’re certain won’t change, there’s a better solution out there! and it is Compound component pattern.

Let's see how the code will look like in this pattern.

// given an Item, renders a Product component with all sub components
const renderAsStoreProduct = (product: Item) => {
  return (
    <ProductCard>
      <ProductCard.Image src={product.image} />
      <ProductCard.Name>{product.name}</ProductCard.Name>
      <ProductCard.Color>{product.color}</ProductCard.Color>
      <ProductCard.Price>{product.price}</ProductCard.Price>
    </ProductCard>
  );
};

// given an Item, renders a Product component with only image and product name
const renderAsFavoriteProduct = (product: Item) => {
  return (
    <ProductCard>
      <ProductCard.Image src={product.image} />
      <ProductCard.Name>{product.name}</ProductCard.Name>
    </ProductCard>
  );
};

// given an Item, renders a Product component with image, name and price
const renderAsPosterProduct = (product: Item) => {
  return (
    <ProductCard>
      <ProductCard.Image src={product.image} />
      <ProductCard.Name>{product.name}</ProductCard.Name>
      <ProductCard.Price>{product.price}</ProductCard.Price>
    </ProductCard>
  );
};

Looks cleaner right? Let's analyse the code. The main component is ProductCard component. ProductCard component has sub components, each representing a part of the Product, such as product Image, name, color and price. We can choose which of these sub components should be rendered, without worrying about the rendering logic. ProductCard is no longer responsible for controlling render logic, and we are not repeating ourselves.

Cool. But how we can implement this? Let's start with ProductCard component.

type ProductCardProps = ViewProps & PropsWithChildren
const ProductCard = ({ children, ...rest }: ProductCardProps) => {
  return <View {...rest}>{children}</View>;
};

This component simply renders its children in a View. ViewProps are passed to the actual View component to enable customizations, such as styles.

Next, let's have a look at how to implement each children of ProductCard.

ProductCard.Image = (imageProps: ImageProps) => {
  return <Image {...imageProps} />;
};

ProductCard.Name = ({ children, ...rest }: TextProps & PropsWithChildren) => {
  return <Text {...rest}>{children}</Text>;
};

ProductCard.Color = ({ children, ...rest }: TextProps & PropsWithChildren) => {
  return <Text {...rest}>{children}</Text>;
};

ProductCard.Price = ({ children, ...rest }: TextProps & PropsWithChildren) => {
  return <Text {...rest}>{children}</Text>;
};

Here, we are assigning each child component as a property to ProductCard component. "What sorcery is this?" you might ask if you are new to JS. Well, functions are just objects in javascript. Therefore, we can add and access properties to functions. Note that property names are capitalized. This is because React requires the component names must start with a capital letter.

If you look closer, it may look like same code is repeated for Name, Color and Price. They all receives TextProps and renders a Text component. Isn't this code repetition? well, no. Remember in this example we are omitting styles for simplicity. in a real scenario, Name would have different styles than Color or Price. With this pattern we can easily customize styles of each child component of ProductCard. For example this is how you would style Name component.

...
<ProductCard>
  <ProductCard.Name 
    numberOfLines={2}
    style={{
      fontSize: 24,
      fontWeight: "bold",
    }}>
    {product.name}
</ProductName>

You can also define default styles inside each child, or following the above example, you can customize how each child component should look like without modifying the actual component. Either way your component is now open for extension but closed for modifications.

The code works fine, but there is a problem. In the current setup, the child components can be used without the parent. For example, nothing stops someone from doing this.

const SomeOtherComponent = () => {
  return (
    <View>
      <ProductCard.Name>
        someone wanted this text to be bold and large, just like product name. So, he used Product.Name component because it has same styling.
      </ProductCard.Name>
    </View>
}

This code isn’t communicating as well as it could be. To fix this, we can use the React context API. There are two main advantages to using context for this. First, we can make sure that child components like Product.Name are rendered inside their parent ProductCard. Second, we can share a value that can be used by all the children of ProductCard.

Let's create the context first.

const productCardContext = createContext<Item | null>(null);

const useProductCardContext = () => {
  const value = useContext(productCardContext);
  if (!value) {
    throw new Error(
      "context value cannot be accessed outside productCardContext.Provider",
    );
  }
  return value;
};

The shared value of productCardContext is some object of type Item, and we are using useProductCardContext custom hook to access this value. The hook ensures it is invoked inside productCardContext. It throws an error if this hook is called outside the context.

Now that we have the context, let's modify our ProductCard parent component and its children components.

Here's the updated ProductCard.

type ProductCardProps = PropsWithChildren & {
  item: Item;
  viewProps: ViewProps;
};

const ProductCard = ({ item, viewProps, children }: ProductCardProps) => {
  return (
    <productCardContext.Provider value={item}>
      <View {...viewProps}>{children}</View>
    </productCardContext.Provider>
  );
};

The updated ProductCard component is not just a container for its children, but it also acts as a productContextProvider. It takes an Item object as a shared value in context. This way, all the children rendered inside ProductCard will have access to the context value.

Here are the updated children components of ProductCard.

ProductCard.Image = (imageProps: ImageProps) => {
  const item = useProductCardContext();
  return <Image {...imageProps} src={item.image} />;
};

ProductCard.Name = (textProps: TextProps) => {
  const item = useProductCardContext();
  return <Text {...textProps}>{item.name}</Text>;
};

ProductCard.Color = (textProps: TextProps) => {
  const item = useProductCardContext();
  return <Text {...textProps}>{item.color}</Text>;
};

ProductCard.Price = (textProps: TextProps) => {
  const item = useProductCardContext();
  return <Text {...textProps}>{item.price}</Text>;
};

In each child component, we leverage the useProductCardContext custom hook we crafted earlier to access the item. This hook allows us to access the shared value (item) across all components.

With these updated components now we can use our ProductCard like this.

const renderAsStoreProduct = (product: Item) => {
  return (
    <ProductCard item={product}>
      <ProductCard.Image />
      <ProductCard.Name />
      <ProductCard.Color />
      <ProductCard.Price />
    </ProductCard>
  );
};

const renderAsFavoriteProduct = (product: Item) => {
  return (
    <ProductCard item={product}>
      <ProductCard.Image />
      <ProductCard.Name />
    </ProductCard>
  );
};

const renderAsPosterProduct = (product: Item) => {
  return (
    <ProductCard item={product}>
      <ProductCard.Image />
      <ProductCard.Name />
      <ProductCard.Price />
    </ProductCard>
  );
};

Because an Item is shared via the context, we no longer need to pass props to each child. it makes the code more clean and declarative.

So, next time you need to show the same component in different spots, remember the compound pattern!

summary

The compound component pattern is a fantastic way to manage UI tweaks in React components. It’s like having a main component that’s like the boss, and then you have sub-components for each part of the UI. This way, you can easily change things without having to copy and paste code all over the place. Plus, it’s super easy to read and customize, making it a great choice for anyone who wants to keep their code clean and organized.

Different project structures for React Apps.

Nisal Tharaka — Thu, 02 Jan 2025 06:48:43 +0000

The structure of a software project is one of the key factors in deciding success or failure. This includes the application architecture, as well as the development process and the whole project organization.The bigger the project is, the more developers that work on the project, and the longer a project runs, the more important it is to have a good project structure. But small projects can also fail because of a bad structure.

Before proposing a recommended project structure, let’s look at the typical components of a modern frontend project. Understanding these components will provide a foundation for designing an effective project structure.

1. Source code: This is the heart of your application and contains the JavaScript/TypeScript files that contain your application’s logic, HTML files for structure, and style files for appearance. Everything that defines the operation and user interface of your application is found here.

2. Assets: This category holds all the static files, such as images, videos, and fonts, that are utilized by your application.

3. Configuration: These files hold important parameters that control various aspects of your application. eg : package.json, .env

4. Tests: This category is dedicated to ensuring the correctness and stability of your application. It holds all the unit, integration, and end-to-end tests that simulate user behavior, validate interactions, and check the functionality of your application, helping to catch and prevent potential bugs.

5. Documentation: This is where all the informative documents of your application reside. From the README file providing an overview of the project to the API documentation and the style guide for coding, these documents help maintain consistency, understanding, and ease of use for anyone interacting with the project.

6. Build artifacts: These are the outputs of the build process, including bundled and optimized JavaScript, CSS, and HTML files ready for deployment, and other temporary or diagnostic files that help debug build issues. They’re key to distributing your application to end users.

Collectively, these diverse components form the foundation of a typical React code base, highlighting the complexity and breadth of considerations involved in frontend projects.

Now, it’s time we explore some tried-and-tested approaches to structuring our code. These strategies aim to simplify the development process and make life easier for developers.

Feature-based structure

The application is organized based on features or modules. Each feature contains its own set of components, views, API calls, and state management, allowing for clear separation and encapsulation of functionality.

With a feature-based architecture in the context of online shopping, you can organize your files and folders as follows:

features/: Represents different features of the application, such as Home, Cart, ProductDetails, Checkout, Profile, and more. Each feature has a folder containing components, containers, pages, services, types, and utils related to that feature.
shared/: contains reusable components, containers, services, types, and utils that can be shared across multiple features.
api/: contains modules for making API calls
store/: directory contains modules for state management (for example, Redux)
router/: directory contains the routing configuration and related components
App.tsx: file serves as the entry point of the application

Component-based structure

The application is organized around reusable components. Components are categorized based on their functionality and can be composed together to build larger views.

With a component-based architecture in the context of online shopping, you can organize your files and folders as follows:

components/: folder contains individual components related to various features of the online shopping application. Each component is organized into a folder, which may contain child components as necessary.
routes/: folder handles frontend routing in the application. It includes the main AppRouter.tsx file, which configures the routing logic, and the routes.tsx file, which defines the individual routes and their corresponding components.
api/: folder contains separate files for different API domains or functionalities. These files, such as products.ts, cart.ts, auth.ts, and payment.ts, handle the API calls related to their respective domains.

Atomic design structure

The key idea behind atomic design is to create a systematic approach to building UI components that encourages reusability, scalability, and maintainability. It provides a clear structure for organizing and naming components, making it easier to understand and navigate the UI code base.

Here’s how the atomic design methodology categorizes UI components:

Atoms: Atoms are the smallest building blocks of a UI and represent individual elements such as buttons, inputs, icons, or labels. They are typically simple and self-contained.
Molecules: Molecules are combinations of atoms and represent more complex UI components. They encapsulate a group of atoms working together to form a functional unit, such as a form field or a navigation bar.
Organisms: Organisms are larger components that combine molecules and/or atoms to create more significant sections of a UI. They represent distinct sections of a user interface, such as a header, sidebar, or card component.
Templates: Templates provide a layout structure for arranging organisms and/or molecules. They define the overall skeleton of a page or a specific section of a UI.
Pages: Pages represent complete user interface screens that are composed of templates, organisms, molecules, and atoms. They
represent the final output visible to the user.

With an atomic design architecture in the context of online shopping, you can organize your files and folders as follows:

atoms/, molecules/, organisms/, templates/, and pages/: directories represent the different levels of component composition and abstraction.
api/: directory contains the API-related files for making API calls.
views/: directory contains the individual views that render the components.
routes/: directory handles the routing configuration

The MVVM structure

The MVVM structure is a software architectural pattern that’s primarily used in building user interfaces:

The Model represents the actual data and/or information we are dealing with. This could be a database, a file, a web service, or even a simple object.

The View is what the user sees and interacts with. It’s the user interface that presents the Model to the user.

The ViewModel is where most of the logic resides in this pattern. It is an abstraction of the View that exposes public properties and commands, bridging the gap between the View and the Model, and processes the data from the Model into a format that is easy for the View to handle. It can perform operations on the data and decide how it should be presented to the View.

To structure a React application with the MVVM architecture in the context of online shopping, you can organize your files and folders as follows:

components/: directory contains reusable UI components, organized by their respective features
models/: directory includes the data models or entities representing the application’s domain objects, such as CartItemModel and ProductModel
viewmodels/: directory holds the Hooks responsible for managing the state, logic, and interactions of the views.
services/: directory contains modules for handling API calls and other external services
views/: directory includes the view components that display the UI based on the ViewModel state
routers/: directory houses the routing configuration and components
App.tsx: file serves as the entry point of the application

Summary

We discussed various styles of structuring a React application, including feature-based, component-based, MVVM, and atomic design. Each approach offers its benefits and considerations, allowing developers to choose the most suitable structure for their specific project requirements. By staying proactive in shaping the folder structure, developers can mitigate the challenges of managing a large React application and ensure maintainability and scalability in the long run.