Funktionsbasierte Reaktionskomponenten

React wird zu einem Full-Stack-Framework mit React-Serverkomponenten und Serveraktionen. Während React Server Components (RSC) es uns ermöglicht, Daten in der Benutzeroberfläche aus der Datenbank zu lesen, ermöglichen uns Serveraktionen, Daten zurück in die Datenbank zu schreiben. Sicherlich werden Benutzeroberfläche und Datenbank in einer kleinen Anwendung eng beieinander liegen und einfach sein, aber in einer größeren Anwendung wird es immer die Komplexität unbeabsichtigter ineinandergreifender vertikaler Funktionen geben.

Hier möchte ich diskutieren, wie man in React eine funktionsbasierte Architektur erstellt, die die Erstellung und Wartung großer Anwendungen ermöglicht. In einer Feature-basierten Architektur ist jedes Feature so weit wie möglich von den anderen entkoppelt. Auf diese Weise können wir die Komponenten und ihre Datenabruffunktionen auf ihre Domäne konzentrieren.

Funktionsbasierte Reaktionskomponenten

In einer typischen Anwendung verfügen wir über eine Datenbank mit mehreren Tabellen, die miteinander in Beziehung stehen. Beispielsweise könnte eine Blog-Anwendung über eine Benutzertabelle, eine Beitragstabelle und eine Kommentartabelle verfügen. Die Posts-Tabelle könnte einen Fremdschlüssel für die Benutzertabelle haben, und die Kommentartabelle könnte Fremdschlüssel sowohl für die Benutzer- als auch für die Posts-Tabelle haben.

Lassen Sie uns der Einfachheit halber die Beziehung zwischen Beiträgen und Kommentaren ohne Berücksichtigung der Benutzertabelle betrachten und sehen, wie sie die Architektur beeinflusst:

Modellbeitrag {
id String @id @default(cuid())
Titelzeichenfolge
Inhaltszeichenfolge
Kommentare Kommentar[]
}

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

In einer React-Komponentenstruktur verfügen wir möglicherweise über eine Post-Komponente, die einen Beitrag und seine Kommentare rendert. Die Post-Komponente könnte als Serverkomponente etwa so aussehen, wobei wir den Beitrag und seine Kommentare aus der Datenbank abrufen:

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

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

zurück (

<>{post.title}

{post.content}

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

);
}

Um unsere Komponenten jedoch fokussiert zu halten, möchten wir die Post-Komponente möglicherweise in zwei Komponenten aufteilen: eine Post-Komponente, die den Beitrag selbst rendert, und eine Comments-Komponente, die die Kommentare rendert. Wir konzentrieren jede Komponente auf ein einzelnes Feature und können daher auch eine saubere Feature-basierte Architektur durchsetzen:

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

const Post = async ({ postId }: { postId: string }) => {
const post = waiting getPost(postId);
zurück (

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

);
}

Das Aufteilen von Komponenten in kleinere Komponenten ist eine bewährte Vorgehensweise, die viele Vorteile mit sich bringt. Hier möchten wir uns auf die Feature-Architektur konzentrieren und darauf, wie sie jede Datei in ihrem eigenen Feature-Ordner vereinfacht, indem Features so weit wie möglich entkoppelt werden

Quelle

Das obige ist der detaillierte Inhalt vonFunktionsbasierte Reaktionskomponenten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!