Feature-Based React Components

React is becoming a full-stack framework with React Server Components and Server Actions. While React Server Components (RSC) allow us to read data in the UI from the database, Server Actions enable us to write data back to the database. Certainly UI and database will be close and simple in a small application, but in a larger application, there will always be the complexity of unintentionally intertwining vertical features.

Here I want to discuss how to create a feature-based architecture in React that allows large scale applications to be built and maintained. In a feature-based architecture, each feature is decoupled from the others as much as possible. This way we can keep the components and their data fetching functions focused on their domain.

Feature-Based React Components

In a typical application, we will have a database with multiple tables that are related to each other. For example, a blog application might have a users table, a posts table, and a comments table. The posts table might have a foreign key to the users table, and the comments table might have foreign keys to both the users and posts tables.

Let's take the posts and comments relationship without taking the user table into consideration, for the sake of simplicity, and see how it will influence the architecture:

model Post {
id String @id @default(cuid())
title String
content String
comments Comment[]
}

model Comment {
id String @id @default(cuid())
content String
post Post @relation(fields: [postId], references: [id])
postId Int
}

In a React component structure, we might have a Post component that renders a post and its comments. The Post component, as a Server Component, might look something like this, where we fetch the post and its comments from the database:

import { getPost } from '@/features/post/queries/get-post';

const Post = async ({ postId }: { postId: string }) => {
const post = await getPost(postId);

return (

<>{post.title}</>

{post.content}

{post.comments.map((comment) => (
• {comment.content}
))}

);
}

However, in order to keep our components focused, we might want to split the Post component into two components: a Post component that renders the post itself, and a Comments component that renders the comments. We focus each component on a single feature and therefore can also enforce a clean feature-based architecture:

import { Comments } from '@/features/comment/components/comments';
import { getPost } from '@/features/post/queries/get-post';

const Post = async ({ postId }: { postId: string }) => {
const post = await getPost(postId);
return (

<>{post.title}</>
<>{post.content}</>
comments{post.comments}
/>

);
}

Splitting up components into smaller components is a best practice which comes with many advantages. Here we want to focus on the feature architecture and how it simplifies each file in its own feature folder by decoupling features as much as possible

Source