wtclaude
3f90070566
Phase 5a gave templates a table, a renderer and nine seeded rows; nothing could
change one. This is the screen that lets an operator change one without being able
to break the mail the system depends on — plus the two screens Q4 promised Phase 5:
Triggers (read-only, from the registries) and the Send Log, which closes G15.
The shape follows from one fact: a mail body is rendered by the SERVER, so the
preview is too, and framed rather than redrawn in React. A client-side renderer
would be a second implementation of the one artifact that matters, agreeing with
the send path on the day it was written and drifting from the first Outlook fix on.
Settled with the org lead before any code: a shipped default is edited IN PLACE
(`protected` blocks deletion and nothing else, `customized = 1` keeps the edit);
duplicate is the only way to a new template; `renderByKey` now requires
`published`; a test send is logged under a synthetic `core.admin.test-send`; and a
template a rule points at refuses deletion with a 409 naming the rules.
Three things the plan did not know, found by building it:
- The undeclared-variable check cannot be a token scan. `email.itemList.variable`
holds a BARE name, so a digest pointed at `itmes` would have saved clean and
arrived empty. Blocks now declare `variables(props)`; the editor makes that
field a select over the trigger's list variables so the typo is unavailable.
- A duplicate that drops `seed_key` loses its variable palette, so duplicating
`notify.event` would have been refused for the tokens it was copied with — the
one action §4.6.2 offers, refusing itself. The copy inherits it; `customized`
is what the seeder actually reads.
- `validateEmailBlocks` returns `{ valid, errors }`, not an array, and the first
version tested it with `.length` — so block validation never ran at all.
Also fixes a Phase 4a defect the live walk found, with the org lead's approval: a
rule's template key was checked against a pattern with no dot in it, so no rule
could name any template that exists — §4.6.2's whole duplicate-and-point-a-rule-at-it
workflow was unreachable. Both models now read one pattern.
Verified against the running stack: real multipart mail into a mailpit catcher
including an unsaved draft, the draft/published arms both ways through the real
mailer path, every refusal, and the end-to-end duplicate → rule → 409 walk.
Server 1428 tests green, client 324.
Co-Authored-By: Claude <noreply@anthropic.com>
101 lines
4.4 KiB
JavaScript
101 lines
4.4 KiB
JavaScript
// ── The client-side `email.*` block registry ───────────────────────────────
|
|
//
|
|
// ENGAGEMENT.md §4.6.2, Phase 5b. A sibling of `blocks/registry.js` for the same
|
|
// reason its server counterpart is a sibling of `blocks/registry.js` on that side
|
|
// — and with ONE structural difference that is the whole argument for the shape of
|
|
// this screen:
|
|
//
|
|
// **an email block definition here has no `component`.**
|
|
//
|
|
// A page block carries a React renderer because a page IS React. A mail body is a
|
|
// string this deployment's server produces, and the preview shows exactly that
|
|
// string. Giving these entries a React renderer would mean two renderers for one
|
|
// artifact — one drawing the editor's preview, one producing what actually lands
|
|
// in someone's inbox — and nothing would make them agree. They would agree on the
|
|
// day they were written and drift from the first Outlook fix onward, at which
|
|
// point the preview becomes a confident lie about mail nobody can see.
|
|
//
|
|
// So the division is: **this registry owns authoring, the server owns rendering.**
|
|
// Everything here is about the editing experience — the palette entry, the prop
|
|
// form, the starting props — and the preview arrives from
|
|
// `POST /admin/engagement/templates/:id/preview` as HTML that goes into a
|
|
// sandboxed iframe.
|
|
//
|
|
// `type` and `version` must match the server definition in
|
|
// `server/src/emailBlocks/types/`. That pairing is the same discipline the page
|
|
// family already runs on, and the save is the thing that enforces it: the server
|
|
// validates against its own registry, so a client entry that has drifted produces
|
|
// a refused save rather than a bad row.
|
|
|
|
const registry = new Map()
|
|
|
|
// The same reserved envelope keys the server's `RESERVED_KEYS` names. Duplicated
|
|
// rather than imported because the client cannot import from `server/`, exactly as
|
|
// `blocks/registry.js` duplicates them — and, as there, the server is the one that
|
|
// decides: a block this list let through is still refused at the save.
|
|
export const RESERVED_KEYS = ['id', 'type', 'version', 'visible', 'props']
|
|
|
|
/**
|
|
* Register an email block definition.
|
|
*
|
|
* @param {object} def
|
|
* @param {string} def.type must match the server type, e.g. 'email.heading'
|
|
* @param {number} def.version must match the server schema version
|
|
* @param {string} def.label palette display name
|
|
* @param {string} def.icon palette icon glyph
|
|
* @param {Function} def.editor ({ props, onChange, variables }) => JSX
|
|
* @param {Function} def.defaults starting props when the block is added
|
|
*/
|
|
export function registerEmailBlock(def) {
|
|
if (!def || typeof def.type !== 'string' || !def.type.startsWith('email.')) {
|
|
throw new Error('registerEmailBlock: a definition needs a type namespaced "email."')
|
|
}
|
|
if (registry.has(def.type)) {
|
|
throw new Error(`registerEmailBlock: block type already registered: ${def.type}`)
|
|
}
|
|
const entry = {
|
|
type: def.type,
|
|
version: Number.isInteger(def.version) ? def.version : 1,
|
|
label: def.label || def.type,
|
|
icon: def.icon || null,
|
|
// The one-line description under the palette button. Mail blocks are less
|
|
// self-evident than page ones — "Item list" does not say that it repeats over
|
|
// a variable — and the palette is where that has to be said.
|
|
hint: def.hint || '',
|
|
editor: def.editor || null,
|
|
defaults: typeof def.defaults === 'function' ? def.defaults : () => ({}),
|
|
}
|
|
registry.set(entry.type, entry)
|
|
return entry
|
|
}
|
|
|
|
/** @returns {object|null} the definition for `type`, or null if unknown. */
|
|
export function getEmailBlock(type) {
|
|
return registry.get(type) || null
|
|
}
|
|
|
|
/** @returns {object[]} every definition, in registration order — the palette. */
|
|
export function listEmailBlocks() {
|
|
return [...registry.values()]
|
|
}
|
|
|
|
/**
|
|
* A fresh block envelope of `type`, ready to push onto the array.
|
|
*
|
|
* The id is random rather than sequential because block ids are unique across the
|
|
* whole document and an operator can delete block 2 and add another; a counter
|
|
* would hand out an id that is already taken and the save would be refused for a
|
|
* reason nothing on screen explains.
|
|
*/
|
|
export function newEmailBlock(type) {
|
|
const def = getEmailBlock(type)
|
|
if (!def) return null
|
|
return {
|
|
id: `b${Math.random().toString(36).slice(2, 10)}`,
|
|
type: def.type,
|
|
version: def.version,
|
|
visible: true,
|
|
props: def.defaults(),
|
|
}
|
|
}
|