# Das Node-Modell > Was alle Nodes gemeinsam haben, worin sie sich unterscheiden und wo jeder von ihnen dokumentiert ist. Source: https://docxcelerate.com/de/docs/nodes/overview/ Ein Dokument ist ein Baum aus Nodes. Jeder Node ist drei Dinge: eine **id**, eine **Art** und eine Regel, die Inhalt erzeugt. ```tsx Dear {state.name}, {/* the rule */} ``` Gegen Ihre Daten aufgelöst, wird daraus reines JSON: ```json { "id": "greeting", "kind": "paragraph", "mode": "static", "text": "Dear Adaeze Nkemelu," } ``` Kein Styling, kein Layout. Das gehört dem Renderer. ## Der Katalog Jeder Typ hat eine eigene Seite, mit jeder Option, die er annimmt, und einer Vorschau zu jeder Schreibweise. ### Struktur - **[Section](https://docxcelerate.com/de/docs/nodes/section/)** (`section`) — Groups nodes under a titled heading. - **[Table of contents](https://docxcelerate.com/de/docs/nodes/table-of-contents/)** (`tableOfContents`) — A marker for a contents list, ahead of the renderers that build one. ### Text - **[Paragraph](https://docxcelerate.com/de/docs/nodes/paragraph/)** (`paragraph`) — A block of prose, written from your data or generated from prompts. ### Medien - **[Image](https://docxcelerate.com/de/docs/nodes/image/)** (`image`) — A picture resolved from your data or described by a prompt. - **[Shape](https://docxcelerate.com/de/docs/nodes/shape/)** (`shape`) — A drawn rectangle with the document's own words on top of it. - **Clip art** (`clipArt`) _(Geplant)_ — Named visual blocks — rules, marks, callouts — drawn by the renderer. ### Daten - **[Graph](https://docxcelerate.com/de/docs/nodes/graph/)** (`graph`) — A real Word chart, declared as data. - **[Table](https://docxcelerate.com/de/docs/nodes/table/)** (`table`) — A grid of cells, with the columns declared once. ## Ids sind Adressen Über die id eines Nodes spricht ein Generierungs-Endpoint genau diesen Absatz an, und über sie liegen zwei Build-Artefakte in einem Diff nebeneinander. Eine Umbenennung bricht alles, was von außen darauf zeigt — genau wie das Umbenennen einer API-Route. Halten Sie sie im Dokument eindeutig. Das kostet nichts und macht Logs lesbar. ## Woher der Inhalt kommt Jeder Node hat entweder seinen Inhalt oder Prompts, um ihn zu erzeugen, und das entscheidet die Komponente, statt dass es irgendwo deklariert würde. Geben Sie einem Absatz Text — oder einem `Image` ein `src`, oder einem `Graph` seine `data` —, und er löst auf Ihrem Rechner auf. Geben Sie ihm stattdessen Prompts und einen Platzhalter, wird er zur Anfragezeit ausgefüllt. Beide lösen zur selben `kind` auf und unterscheiden sich im gebauten Dokument durch `mode`. `mode` ist Ausgabe, nicht Eingabe: Der Build leitet es aus dem ab, was die Komponente angegeben hat, und das Paket sagt einer Engine, welche Nodes sie auflösen muss. Beides an einem Element anzugeben ist ein Fehler und kein Münzwurf. [Nodes schreiben](/de/docs/writing-nodes/) behandelt die Prompt-Slots und was Vorschauen an ihrer Stelle zeigen. ## Verschachtelung [`section`](/de/docs/nodes/section/) ist heute der einzige Node, der Kinder aufnimmt, und er akzeptiert jede Art, auch weitere Abschnitte. Ein Tabellen-Node mit Nodes in seinen Zellen kommt als Nächstes, nach demselben Prinzip: Container nehmen die Komponenten auf, die Sie ohnehin schreiben, statt daneben ein zweites Inhaltsmodell zu stellen. ## Zu diesen Vorschauen Jede Vorschau hier ist ein echter Build. `src/nodes/` im Repository dieser Site enthält eine Datei je Variante, geschrieben gegen das veröffentlichte Paket; ein Build-Schritt löst jede davon über `buildDocument` auf und rendert sie mit dem Renderer, den `dxcl dev` ausliefert. Der gezeigte Quelltext ist die Datei, die gelaufen ist, und das JSON ist das, was zurückkam — diese Seiten gehen also laut kaputt, statt still zu veralten.