Base de conhecimento

Modelos

Um corpo escrito uma vez, versionado e enviado muitas vezes: a partir do compositor, do seu próprio código ou por um agente.

Detalhes

Um modelo pertence à ligação e não à pessoa que o escreveu, que é precisamente a razão por que a primeira versão disto foi substituída. Essa estava indexada ao utilizador: o modelo de um colega era invisível para uma chave de API do espaço de trabalho, pelo que uma integração não conseguia enviar aquilo que a pessoa que a configurou via, e apagar a conta do autor levava com ela os modelos do espaço de trabalho. As linhas foram migradas, não descartadas.
Duas formas de escrever um corpo. Uma árvore de blocos sobre os componentes de @react-email/components (Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock, CodeInline), validada à medida que é escrita, para que um nó inválido ou um href inseguro seja recusado na chamada que o escreveu em vez de chegar como um email avariado. Ou marcação que renderizou por si: se os seus modelos já são componentes react-email no seu próprio repositório, renderize-os aí com @react-email/render e envie o HTML, que é sanitizado uma vez quando a versão é publicada.
Vinte e três pontos de partida e um em branco, numa galeria e não num menu, porque são coisas que é preciso ver antes de escolher entre elas, por isso cada cartão mostra o próprio email. Boas-vindas e verificação, recibos e faturas, envios e renovações, resumos e anúncios, organizados sob quatro títulos, e cada um abre no editor visual com todas as peças móveis, reestilizáveis e elimináveis. Aquele que escolher chega como rascunho, por isso nada é enviável até o publicar.
A galeria é a única parte disto que só existe na aplicação. Quem chega aos modelos a partir do seu próprio código ou de um agente envia um corpo (um documento de blocos ou a sua própria marcação) em vez de indicar um ponto de partida, pelo que os vinte e três são um sítio por onde começar e não um catálogo a partir do qual instalar.
Os slots com nome e as props com nome são os dois tipos de lacuna, escritos como {{key}} no corpo e no assunto. Um slot é preenchido por quem edita o modelo e tem um valor por omissão, pelo que um envio que não indique nada continua a renderizar. Uma prop é fornecida no envio, e uma marcada como obrigatória recusa o envio quando falta: um 422, e não sai correio. Essa recusa é a razão para a declarar: a alternativa é uma mensagem que sai com um espaço em branco onde devia estar o número da encomenda, coisa que nada assinala e ninguém consegue recuperar.
Uma versão publicada está congelada. Editar o corpo de um modelo publicado cria um novo rascunho em vez de reescrever o que está em vigor, pelo que os envios continuam a resolver o que resolviam ontem até alguém publicar, e um envio que fixa um número de versão nem assim é afetado. O corpo é compilado na publicação, que é o que faz com que um modelo que não renderiza falhe para quem o publica e não para um destinatário.
A pré-visualização renderiza exatamente o que um envio produziria sem o enviar, e indica o que continua vazio em vez de recusar. Um modelo a ser pré-visualizado é normalmente um modelo a ser escrito, e um autor que preenche um bloco de cada vez não deve ter de satisfazer todas as props para ver o que já tem.
Cada modelo tem o seu próprio registo do que enviou: quantas mensagens saíram nos últimos sete, trinta ou noventa dias, quais delas foram abertas e em quais houve cliques, uma série dia a dia, e uma divisão pela origem de cada envio: o compositor, o seu código, um agente ou a fila. Cada taxa indica o seu próprio denominador em vez de pedir um emprestado, porque são genuinamente diferentes: as aberturas são contadas sobre as mensagens que levavam um pixel, os cliques sobre as mensagens que levavam uma ligação reescrita, e uma mensagem pode levar uma coisa sem a outra. Uma pré-visualização nunca é registada, e um envio de teste é contado à parte e deixado de fora de todos os números, porque nunca chegou a sair.
Esse registo é honesto sobre o que não consegue ver, que é a razão para confiar na metade que consegue. Um envio é associado ao seu registo de entrega pelo próprio envio, e só o correio enviado a partir do seu próprio código ou da fila leva um. Uma mensagem enviada a partir do compositor, por um agente ou pelo assistente não leva. Por isso, um modelo usado sobretudo a partir do compositor chega com a maioria dos envios sem associação, e a contagem dos não associados é apresentada como um número próprio, em vez de ser somada como se ninguém a tivesse aberto.
Quatro superfícies sobre um serviço, para que “o que significa publicar” tenha uma resposta em vez de três que hoje concordam. O botão Modelos do compositor oferece os publicados e SUBSTITUI a mensagem por aquele que escolher, em vez de o colar lá dentro: o envio indica o modelo, a versão é fixada no momento em que o escolhe, e o corpo é renderizado onde foi escrito, pelo que uma publicação entre a escolha e o clique não pode alterar o que sai, e um layout que o compositor nunca conseguiria conter sobrevive intacto. O que preenche ali são os valores, não o corpo. /templates são nove endpoints atrás dos âmbitos templates:read e templates:write, envolvidos método a método pelo SDK. Enviar um precisa de uma permissão de envio além de uma permissão de modelos, pelo que uma chave emitida a uma ferramenta de copywriting pode escrever e publicar sem conseguir enviar correio a ninguém. O servidor MCP tem cinco ferramentas: listar, ler, pré-visualizar, criar e enviar. Deliberadamente, não há nenhuma ferramenta para atualizar, apagar ou publicar um modelo existente. Uma edição cria um rascunho para o qual o envio seguinte não resolveria, e uma eliminação não pode ser desfeita. Editar um corpo guardado é um ecrã: /workspace/templates tem uma tela de blocos com uma paleta e um inspetor, uma pré-visualização ao lado, e Guardar e Publicar como atos separados, que é o que faz de uma versão publicada algo que pode deixar em paz enquanto trabalha na seguinte.
200 modelos por ligação, um documento de blocos limitado a 500 blocos, oito níveis de aninhamento, 20 000 caracteres em cada valor e 100 slots e 100 props; um corpo enviado como marcação limitado a um milhão de caracteres, e um assunto a 998. Cada um destes é uma proteção contra um script descontrolado e não um limite de plano, cada um recusa com uma mensagem que indica o número em que recusou, e nada nos modelos está atrás de um escalão.