Wie das Rendering funktioniert

Templatical trennt die Template-Bearbeitung vom Template-Rendering. Der Editor erzeugt JSON; der Renderer wandelt dieses JSON in MJML um. Anschließend kompilieren Sie das MJML mit einer beliebigen MJML-Bibliothek zu HTML und versenden es über Ihren E-Mail-Dienst.

Die Pipeline

1. JSON -- Das native Format des Editors. Ein TemplateContent-Objekt mit einem blocks-Array und einem settings-Objekt. Speichern Sie es, damit Nutzer die Bearbeitung später fortsetzen können.

2. MJML -- Eine speziell für E-Mails entwickelte Zwischen-Markup-Sprache. Jeder Templatical-Block wird auf eine MJML-Komponente abgebildet (<mj-text>, <mj-image>, <mj-button> usw.). MJML übernimmt die schwierigen Teile von E-Mail-HTML: responsive Tabellen, Outlook-Conditionals und Kompatibilität mit verschiedenen E-Mail-Clients. Dies ist die Ausgabe des Templatical-Renderers.

3. HTML -- Die finale Ausgabe. MJML kompiliert zu einem vollständigen HTML-Dokument mit Inline-Styles, verschachtelten Tabellen und client-spezifischen Workarounds. Diesen Schritt kompilieren Sie selbst mit einer beliebigen MJML-Bibliothek:

   Sprache	Bibliothek
   Node.js	mjml (offiziell)
   PHP	spatie/mjml-php
   Python	mrml-python
   Ruby	mrml-ruby
   Rust	mrml
   .NET	Mjml.Net
   Elixir	mjml_nif

   Eine vollständige Liste finden Sie auf mjml.io/community.

Warum MJML?

MJML ist eine Open-Source-Markup-Sprache, die speziell für E-Mails entwickelt wurde. E-Mail-HTML ist bekanntermaßen schwierig. Jeder E-Mail-Client rendert HTML anders -- Outlook verwendet die Rendering-Engine von Microsoft Word, Gmail entfernt <style>-Tags, Apple Mail unterstützt modernes CSS, Yahoo dagegen nicht. HTML zu schreiben, das überall funktioniert, erfordert:

• Verschachtelte Tabellen für das Layout (Flexbox und Grid funktionieren nicht)
• Inline-Styles auf jedem Element (externe/eingebettete Stylesheets werden entfernt)
• Outlook-spezifische Conditional Comments (<!--[if mso]>)
• Responsive Breakpoints über <style>-Tags für Clients, die sie unterstützen

MJML abstrahiert all dies. Sie schreiben semantische Komponenten (<mj-section>, <mj-column>, <mj-text>), und MJML kompiliert sie zu kompatiblem HTML.

Indem Templatical MJML statt direkt HTML erzeugt, bleibt es leichtgewichtig und gibt Ihnen die volle Kontrolle über die finale Ausgabe. Sie können einen beliebigen MJML-Compiler in einer beliebigen Sprache verwenden und das MJML vor dem Kompilieren modifizieren – um eigene Komponenten einzufügen, Tracking-Pixel hinzuzufügen oder das Markup an die Anforderungen Ihrer Versandplattform anzupassen.

Was gespeichert werden sollte

JSON — immer. TemplateContent ist die Quelle der Wahrheit: das Einzige, was der Editor wieder öffnen kann, und die einzige Eingabe, die der Renderer braucht.

MJML — nie erforderlich. Es ist eine Ausgabe und lässt sich jederzeit aus dem JSON neu ableiten. Speichern Sie es nur als Cache, und nur dort, wo Sie es sonst zweimal erzeugen müssten:

Wo Sie rendern	Wo @templatical/renderer installiert ist	MJML speichern?
Im Browser — kein render-Provider oder nur compileMjml	in Ihrer Frontend-Anwendung, neben dem Editor	Optional. toMjml() liegt beim Speichern ohnehin vor, das Ergebnis aufzubewahren erspart späteres erneutes Rendern. Der Schnellstart macht das.
Auf Ihrem Backend — Sie implementieren render.toMjml	auf Ihrem Backend — oder gar nicht, wenn es in einer anderen Sprache rendert	Nein. Ihr Backend erzeugt das MJML beim Rendern. Eine Browser-Kopie ist eine zweite Quelle, die davon abweichen kann. Siehe Rendering & Export.
Templatical Cloud	nirgends — Cloud führt den veröffentlichten Renderer serverseitig aus	Nein. Cloud rendert aus der gespeicherten Vorlage und leitet bei Bedarf neu ab. Siehe Rendering auf Cloud.

Ein gespeichertes Render-Ergebnis ist ein Cache

MJML hängt vom JSON und von Ihrem Renderer ab: Ihrer Schriften-Konfiguration, etwaigen blockRenderers-Überschreibungen, der Paketversion selbst. Ändert sich davon etwas, sind gespeicherte Kopien veraltet, während das JSON weiterhin korrekt rendert. Leiten Sie neu ab, statt zu reparieren.

Was der Renderer tut

@templatical/renderer nimmt ein TemplateContent-JSON-Objekt entgegen und erzeugt ein vollständiges MJML-Dokument. Im Einzelnen:

• Konvertiert jeden Block im JSON-Baum in seine entsprechende MJML-Komponente (text → <mj-text>, image → <mj-image>, button → <mj-button> usw.)
• Wendet Blockstile (Padding, Hintergrundfarbe) als MJML-Attribute an
• Setzt die Abstände von <p>, <ul>, <ol> und <li> in Rich-Text so, dass sie dem Editor-Canvas entsprechen, und überschreibt damit MJMLs eigenen Standard p { margin: 13px 0 }
• Fügt benutzerdefinierte Schriftart-Deklarationen als <mj-font>-Tags ein
• Bewahrt Merge-Tags unverändert (sie werden als wörtlicher Text durchgereicht)
• Berücksichtigt visibility-Einstellungen -- auf allen Viewports ausgeblendete Blöcke werden ausgelassen
• Umschließt Blöcke mit displayCondition-Before/After-Strings
• Entfernt optional rohe HTML-Blöcke, wenn allowHtmlBlocks auf false gesetzt ist

Was der Renderer NICHT tut

• MJML zu HTML kompilieren -- Verwenden Sie dafür eine beliebige MJML-Bibliothek.
• Merge-Tags auswerten -- Tags wie {{ first_name }} werden unverändert durchgereicht und zum Versandzeitpunkt von Ihrer E-Mail-Plattform ersetzt.
• Anzeigebedingungen auswerten -- Bedingte Umschließung (z. B. {% if %}) wird zur Verarbeitung durch Ihre Versandplattform unverändert durchgereicht.
• E-Mails versenden -- Der Renderer erzeugt MJML. Der Versand wird von Ihrem E-Mail-Dienst übernommen.
• Bilder optimieren -- Bilder werden per URL referenziert. Der Renderer lädt, skaliert oder optimiert sie nicht.

Nächste Schritte

• Renderer-API -- vollständige renderToMjml()-Referenz