Repository navigation
Conversation
Demonstrate editing a `@comet/mail-react` email in the admin: a scoped Welcome Email document with a live preview of the mail the site renders from it. - **MJML rendering happens in the site, not the API.** Rendering `@comet/mail-react` runs React on the frontend, so the API stays a data service and fetches the finished HTML from the site to send test mails.
Give the demo a representative set of `@comet/mail-react` content blocks to build the Welcome Email from. - **The rich-text editor offers only the styles the block defines.** By default it also exposes heading levels the block has no variant for, letting authors pick styles it cannot represent. - **Rich-text links can target phone numbers, not only URLs.** The phone type demonstrates the rich text's support for custom link types beyond the built-in external link.
The admin editor needs an API to load and save the Welcome Email document.
Populate the demo with a Welcome Email so the block-builder feature has a concrete example to open, edit, and render.
The text block style dropdown always showed `Default` for the entry that applies no style. When a block configures named styles such as `Paragraph Default` and `Paragraph Small`, that fixed `Default` is inconsistent with the styles it sits next to. A per-block label lets the entry match the block's naming. - **Relabel the no-style entry instead of making a named style the default.** Making a named style the default (the DraftJS RTE's `standardBlockType` approach) would change stored data and also affect the API package — much more work than a naming change needs. - **Only the text block style dropdown's entry can be relabeled.** The text block type and inline style dropdowns keep `Default`. - **The option lives in the admin package only, though `textBlockStyles` also exists in the API factory.** The label affects only the editor UI; the API handles data and validation, not display strings.
The upcoming Tip-Tap rich-text block needs the same per-node text rendering, link resolution, and built-in mark styling the draft-js block already has, so this moves them into a shared location instead of duplicating them. - **Built-in mark renderers keyed by lowercase name.** Tip-Tap's own mark-type names are already lowercase; draft-js remaps its SCREAMING_CASE inline-style names onto the shared set instead of the other way around.
…t block data Mails whose rich text uses the CMS's new Tip-Tap block have no email renderer. This adds the Tip-Tap counterpart to the existing draft-js rich-text block, so authors can send those mails. - **Hand-rolled recursive walker, no new dependency.** The Tip-Tap rendering library would pin exact peer versions of its core packages onto a mail library that otherwise has none. - **Two style-mapping options for blocks, and two for marks.** Tip-Tap keeps each node's structural type separate from its app-defined style name, and each mark's type separate from its app-defined inline-style name; one option per pair could not key both without collisions. - **Lists render flat, matching the draft-js block.** Outlook breaks nested list padding and margin, the same constraint that already flattens lists there. - **Placeholder nodes render their literal text, unsubstituted.** Recipient values are filled in downstream by the sending service; this package has no reason to know about recipients. - **Embedded child blocks are skipped silently.** Rendering arbitrary application blocks in email is out of scope for this experimental block, recorded as a non-goal in its `README`.
The new Tip-Tap rich-text block had no usage documentation, so consumers building emails and agents working in a project that uses this package had no way to discover it or how its behavior differs from the draft-js block.
Give the Welcome Email a second rich-text option so the Tip-Tap RTE can be authored and rendered side by side with the existing DraftJS one. - Add `MailTipTapRichTextBlock` across api/admin/site, registered under the `tipTapRichText` key in `WelcomeEmailContentBlock`. It mirrors the DraftJS block: `title`/`header` paragraph styles, bold/italic/sub/sup/ strike, and external + phone links. - Relabel the two blocks in the picker so they are distinguishable: "Rich Text (DraftJS)" and "Rich Text (TipTap)". - Use the new `defaultTextBlockStyleLabel` to name the no-style paragraph "Copy" instead of "Default", so Copy reads as the default style and renders as the copy variant — matching the DraftJS block's standard block type. - Seed a Tip-Tap block in the Welcome Email fixture (a Copy paragraph with a phone and an external link, plus a Title) so it renders on a fresh install.
Contributor
Author
|
Closed in favor of #6406 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task: https://vivid-planet.atlassian.net/browse/PHSB2C-12548
Depends on #5972 #6004