Intégrer un éditeur d’email dans votre SaaS

Intégrer un éditeur d’email dans votre SaaS commence par un écran. Pour qu’il soit utile, il faut aussi pouvoir ouvrir un brouillon, le modifier, partir, revenir et envoyer la bonne version.

Pensez donc en parcours documentaire. L’utilisateur travaille dans l’éditeur, mais sa confiance dépend tout autant de ce qui se passe autour : enregistrement, récupération et passage à l’envoi.

Choisir un parcours complet et concret

Prenez un message que vos clients produisent déjà, par exemple une actualité produit mensuelle. Identifiez son auteur, l’origine du contenu initial, l’emplacement du brouillon et les personnes autorisées à l’envoyer. Faites également apparaître le choix de l’audience et les éventuelles validations.

Distinguez le document modifiable, sa révision enregistrée et le message exporté. Le HTML sert à l’envoi ; le document structuré permet de reprendre le travail. Conserver seulement l’export compromet cette reprise, même si le résultat visuel semble identique au départ.

Pour une première intégration, retenez un modèle connu et un destinataire interne. Un petit parcours qui fonctionne de bout en bout permet de découvrir les vrais problèmes plus vite qu’une grande palette de blocs sans persistance.

Initialiser l’éditeur avec le bon contexte

Donnez une hauteur exploitable au conteneur et attendez le chargement du SDK. Avec Weavour, le point d’entrée documenté est Weavour.mount. Fournissez editorKey, userId, éventuellement organizationId, ainsi que la langue d’interface locale. Pour rouvrir un travail existant, transmettez son document.

Les identifiants d’utilisateur et d’organisation sont des espaces de noms déclaratifs au sein de l’espace client déterminé par la clé d’éditeur. Ce ne sont pas des identités vérifiées. Votre application reste responsable de l’authentification et du choix du contexte ; une clé publique d’éditeur n’est pas un accès administrateur.

Utilisez le pont fourni par le SDK. Si vous ajoutez des échanges entre fenêtres, contrôlez l’expéditeur, le format du message et l’origine destinataire. Le standard HTML sur les messages précise les vérifications attendues.

Traiter l’enregistrement comme une vraie opération

Le rappel onChange(document) de Weavour transmet le contenu structuré à l’application hôte. Reliez-le à un enregistrement comportant un identifiant de document et une révision attendue. Ce contrat de révision appartient à votre backend : ce n’est pas un paramètre supplémentaire du SDK.

Supposons que votre actualité soit le brouillon actualite-octobre, révision 12. Un enregistrement réussi crée la révision 13. Si un autre onglet a déjà enregistré cette révision, présentez un conflit à résoudre plutôt que d’écraser son travail.

Les états « enregistrement », « enregistré » et « échec » doivent refléter la réponse du stockage. Recevoir une modification ne prouve pas qu’elle a été conservée. Après une erreur réseau, gardez le contenu courant et proposez une nouvelle tentative. À la fermeture de l’écran, libérez l’instance avec destroy().

Exporter avant de déclencher l’envoi

La méthode documentée exportHTML() renvoie une promesse contenant html, text et document. Gérez son rejet avant de poursuivre. Le rendu et la transmission sont deux opérations distinctes, comme l’illustre la documentation de rendu React Email.

Les accès au service d’envoi restent sur votre backend. Celui-ci vérifie les destinataires, prépare les données personnalisées et contrôle les autorisations. Un export réussi ne doit jamais être présenté comme une livraison réussie.

Joignez la révision utilisée à votre demande d’envoi afin de faciliter les diagnostics. Si seule la dernière version enregistrée peut partir, expliquez cette règle et attendez la fin de l’enregistrement avant l’export.

Vérifier le parcours qui sera répété

Avant d’ajouter d’autres fonctionnalités, réalisez cette recette :

• Modifier un titre, enregistrer, quitter puis rouvrir le document.
• Couper le réseau et vérifier que le texte reste récupérable.
• Modifier depuis deux onglets pour tester le conflit de révisions.
• Changer la langue d’interface sans traduire le contenu rédigé.
• Exporter, contrôler les liens et envoyer vers une boîte interne.
• Revenir dans l’écran sans multiplier les gestionnaires d’événements.

Le premier résultat utile est un brouillon qui traverse tout ce parcours. Stabilisez-le, puis ajoutez les modèles et commandes dont vos clients ont besoin. Découvrez Weavour en gardant votre propre cycle documentaire comme fil conducteur.