Zur Dokumentation springen
Wissensdatenbank

Vorlagen

Ein Inhalt, einmal geschrieben, versioniert und vielfach versendet: aus dem Composer, aus Ihrem eigenen Code oder durch einen Agenten.

Details

  • Eine Vorlage gehört zur Verbindung und nicht zu der Person, die sie geschrieben hat – genau deshalb wurde die erste Fassung davon ersetzt. Jene war am Benutzer verankert: Die Vorlage einer Person aus dem Team war für einen Workspace-API-Key unsichtbar, eine Integration konnte also nicht versenden, was die einrichtende Person sah, und das Löschen des Autorenkontos nahm die Vorlagen des Workspace mit. Die Zeilen wurden übernommen statt verworfen.
  • Zwei Wege, einen Inhalt zu verfassen. Ein Blockbaum über die Komponenten von @react-email/components (Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock, CodeInline), geprüft schon beim Schreiben, sodass ein fehlerhafter Knoten oder ein unsicheres href bereits bei dem Aufruf abgelehnt wird, der ihn geschrieben hat, statt als kaputte E-Mail anzukommen. Oder Markup, das Sie selbst gerendert haben: Wenn Ihre Vorlagen in Ihrem eigenen Repository bereits react-email-Komponenten sind, rendern Sie sie dort mit @react-email/render und senden Sie das HTML, das beim Veröffentlichen der Version einmalig bereinigt wird.
  • Dreiundzwanzig Startpunkte und ein leerer, in einer Galerie statt in einem Menü, denn man muss sie ansehen, bevor man zwischen ihnen wählt, und deshalb zeigt jede Karte die E-Mail selbst. Begrüßung und Verifizierung, Belege und Rechnungen, Versand und Verlängerungen, Zusammenfassungen und Ankündigungen, unter vier Überschriften angeordnet, und jeder öffnet sich im visuellen Editor, in dem sich jedes Element verschieben, umgestalten und löschen lässt. Was immer Sie wählen, kommt als Entwurf an, sodass nichts versendbar ist, bevor Sie es veröffentlichen.
  • Die Galerie ist der einzige Teil davon, den es nur in der App gibt. Wer Vorlagen aus dem eigenen Code oder über einen Agenten anspricht, sendet einen Inhalt (ein Blockdokument oder eigenes Markup), statt einen Startpunkt zu benennen; die dreiundzwanzig sind also ein Ausgangspunkt und kein Katalog, aus dem installiert wird.
  • Benannte Slots und benannte Props sind die zwei Arten von Lücke, geschrieben als {{key}} im Inhalt und im Betreff. Ein Slot wird von der Person gefüllt, die die Vorlage bearbeitet, und trägt einen Standardwert, sodass ein Versand, der nichts benennt, trotzdem rendert. Ein Prop wird beim Versand übergeben, und ein als required markiertes lehnt den Versand ab, wenn es fehlt: ein 422, und es geht keine Mail hinaus. Genau dafür deklariert man es: Andernfalls geht eine Nachricht mit einer Lücke dort hinaus, wo die Bestellnummer stehen sollte – was nichts meldet und niemand zurückholen kann.
  • Eine veröffentlichte Version ist eingefroren. Wer den Inhalt einer veröffentlichten Vorlage bearbeitet, erzeugt einen neuen Entwurf, statt das Live-Geschaltete zu überschreiben; Sendungen lösen also weiterhin das auf, was sie gestern aufgelöst haben, bis jemand veröffentlicht, und ein Versand, der eine Versionsnummer festnagelt, bleibt auch dann unberührt. Der Inhalt wird beim Veröffentlichen kompiliert, und genau deshalb scheitert eine Vorlage, die nicht rendert, bei der veröffentlichenden Person und nicht erst bei einem Empfänger.
  • Die Vorschau rendert genau das, was ein Versand erzeugen würde, ohne zu senden, und meldet, was noch leer ist, statt abzulehnen. Eine Vorlage in der Vorschau ist meist eine Vorlage im Entstehen, und wer sie Block für Block füllt, sollte nicht jedes Prop bedienen müssen, um den bisherigen Stand zu sehen.
  • Jede Vorlage führt eine eigene Aufzeichnung dessen, was sie versendet hat: wie viele in den letzten sieben, dreißig oder neunzig Tagen hinausgingen, welche davon geöffnet und welche geklickt wurden, eine Reihe Tag für Tag und eine Aufteilung danach, woher der jeweilige Versand kam: aus dem Composer, aus Ihrem Code, von einem Agenten oder aus der Queue. Jede Rate nennt ihren eigenen Nenner, statt sich einen zu borgen, denn sie sind tatsächlich verschieden: Öffnungen werden über die Nachrichten gezählt, die ein Pixel trugen, Klicks über die Nachrichten, die einen umgeschriebenen Link trugen, und eine Nachricht kann das eine ohne das andere tragen. Eine Vorschau wird überhaupt nicht erfasst, und ein Testversand wird getrennt gezählt und aus jeder Kennzahl herausgehalten, weil er nie hinausgegangen ist.
  • Diese Aufzeichnung ist ehrlich in dem, was sie nicht sehen kann, und genau deshalb kann man der Hälfte trauen, die sie sieht. Ein Versand wird über sich selbst seinem Zustellungsdatensatz zugeordnet, und nur Mail aus Ihrem eigenen Code oder aus der Queue trägt einen solchen. Eine Nachricht aus dem Composer, von einem Agenten oder vom Assistenten trägt ihn nicht. Bei einer Vorlage, die überwiegend aus dem Composer benutzt wird, bleiben also die meisten Sendungen ohne Zuordnung, und die Zahl der nicht zugeordneten wird als eigene Zahl ausgewiesen, statt als „niemand hat geöffnet“ mitgerechnet zu werden.
  • Vier Oberflächen über einem Dienst, damit „was heißt veröffentlichen“ eine Antwort hat und nicht drei, die sich heute einig sind. Die Schaltfläche Templates im Composer bietet die veröffentlichten an und ERSETZT die Nachricht durch das Gewählte, statt es einzufügen: Der Versand benennt die Vorlage, die Version wird im Moment der Auswahl festgenagelt, und der Inhalt wird dort gerendert, wo er verfasst wurde – eine Veröffentlichung zwischen Auswählen und Klicken kann also nicht ändern, was hinausgeht, und ein Layout, das der Composer nie hätte halten können, bleibt unversehrt. Was Sie dort ausfüllen, sind die Werte, nicht der Inhalt. /templates sind neun Endpunkte hinter den Scopes templates:read und templates:write, vom SDK Methode für Methode gekapselt. Das Versenden braucht neben einer Vorlagenberechtigung auch eine Sendeberechtigung, sodass ein Key, der an ein Texter-Tool ausgegeben wurde, verfassen und veröffentlichen kann, ohne jemandem mailen zu können. Der MCP-Server trägt fünf Tools: list, read, preview, create und send. Ein Tool zum Aktualisieren, Löschen oder Veröffentlichen einer bestehenden Vorlage gibt es bewusst nicht. Eine Bearbeitung erzeugt einen Entwurf, auf den der nächste Versand nicht auflösen würde, und ein Löschen lässt sich nicht zurücknehmen. Einen gespeicherten Inhalt zu bearbeiten ist ein Bildschirm: /workspace/templates trägt eine Blockfläche mit Palette und Inspektor, daneben eine Live-Vorschau und Save und Publish als getrennte Handlungen – und genau das macht eine veröffentlichte Version zu etwas, das Sie in Ruhe lassen können, während Sie an der nächsten arbeiten.
  • 200 Vorlagen pro Verbindung, ein Blockdokument mit höchstens 500 Blöcken, acht Verschachtelungsebenen, 20.000 Zeichen in einem einzelnen Wert sowie 100 Slots und 100 Props; ein als Markup gesendeter Inhalt mit höchstens einer Million Zeichen und ein Betreff mit 998. Jede dieser Grenzen schützt vor einem außer Kontrolle geratenen Skript und ist keine Tarifgrenze, jede lehnt mit einer Meldung ab, die die Zahl nennt, an der sie abgelehnt hat, und nichts an Vorlagen hängt an einer Stufe.