Composants React basés sur les fonctionnalités

React devient un framework full-stack avec les composants React Server et les actions serveur. Alors que les composants React Server (RSC) nous permettent de lire les données de l'interface utilisateur à partir de la base de données, les actions serveur nous permettent de réécrire les données dans la base de données. Certes, l'interface utilisateur et la base de données seront proches et simples dans une petite application, mais dans une application plus grande, il y aura toujours la complexité de l'entrelacement involontaire de fonctionnalités verticales.

Ici, je souhaite expliquer comment créer une architecture basée sur les fonctionnalités dans React qui permet de créer et de maintenir des applications à grande échelle. Dans une architecture basée sur les fonctionnalités, chaque fonctionnalité est autant que possible découplée des autres. De cette façon, nous pouvons garder les composants et leurs fonctions de récupération de données concentrés sur leur domaine.

Composants React basés sur les fonctionnalités

Dans une application typique, nous aurons une base de données avec plusieurs tables liées les unes aux autres. Par exemple, une application de blog peut avoir une table d'utilisateurs, une table de publications et une table de commentaires. La table des publications peut avoir une clé étrangère vers la table des utilisateurs, et la table des commentaires peut avoir des clés étrangères vers les tables des utilisateurs et des publications.

Prenons la relation posts et commentaires sans prendre en considération la table des utilisateurs, par souci de simplicité, et voyons comment cela va influencer l'architecture :

Modèle Post {
id Chaîne @id @default(cuid())
chaîne de titre
chaîne de contenu
commentaires Commentaire[]
>

Commentaire du modèle {
id Chaîne @id @default(cuid())
chaîne de contenu
post Post @relation(champs : [postId], références : [id])
postId Int
>

Dans une structure de composant React, nous pouvons avoir un composant Post qui restitue une publication et ses commentaires. Le composant Post, en tant que composant serveur, pourrait ressembler à ceci, où nous récupérons la publication et ses commentaires dans la base de données :

importer { getPost } depuis '@/features/post/queries/get-post';

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

retour (

<>{post.title}

{post.content}

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

);
}

Cependant, afin de garder nos composants concentrés, nous souhaiterons peut-être diviser le composant Post en deux composants : un composant Post qui restitue la publication elle-même et un composant Commentaires qui restitue les commentaires. Nous concentrons chaque composant sur une seule fonctionnalité et pouvons donc également appliquer une architecture propre basée sur les fonctionnalités :

importer { Commentaires} depuis '@/features/comment/components/comments' ;
importer { getPost } depuis '@/features/post/queries/get-post';

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

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

);
}

La division des composants en composants plus petits est une bonne pratique qui présente de nombreux avantages. Ici, nous souhaitons nous concentrer sur l'architecture des fonctionnalités et sur la façon dont elle simplifie chaque fichier dans son propre dossier de fonctionnalités en découplant les fonctionnalités autant que possible

Source

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!