Skip to content

cms-admin: Add isTextBlockType option to createTipTapRichTextBlock - #6369

Draft
VPS-Andreas wants to merge 1 commit into
tiptap-default-text-block-stylefrom
tiptap-text-block-type-select-style
Draft

VPS-Andreas wants to merge 1 commit into
tiptap-default-text-block-stylefrom
tiptap-text-block-type-select-style

Conversation

@VPS-Andreas

@VPS-Andreas VPS-Andreas commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

Summary

The text block style dropdown was the only way to apply a style like a large "Display" heading variant, even for blocks where that style is really a distinct, editor-facing block type in its own right — some Draft.js RTEs had exactly this: a display block type sitting above header-one, both rendering as <h1>, display a large hero-style variant. That produced two dropdowns where the legacy block had one, and left the style dropdown showing only "Default"/"Heading N" for every other heading level.

A textBlockStyles entry with isTextBlockType: true now shows up as its own entry in the text block type dropdown instead, right above the plain heading level entry it shares a tag with. Picking that plain entry, or any other tag, always clears the style, so it can't linger as a stale value. Requires appliesTo to name exactly one tag, and that tag can't also carry a defaultTextBlockStyles entry, since the two would fight over what "no explicit style" means for it.

Example

createTipTapRichTextBlock({
    paragraph: false,
    heading: { levels: [1, 2, 3, 4, 5] },
    textBlockStyles: [
        {
            name: "display",
            label: "Display",
            appliesTo: ["heading-1"],
            isTextBlockType: true,
            element: (props) => <h1 style={{ fontSize: 56 }} {...props} />,
        },
    ],
});

The type dropdown becomes Display, Heading 1, Heading 2, Heading 3, Heading 4, Heading 5 — matching the legacy single-dropdown block type select.

Stacking note

⚠️ Based on #6366, not main — that PR needs to merge first. Once it does:

  1. git rebase --onto <new main tip> <old tiptap-default-text-block-style tip> tiptap-text-block-type-select-style (same dance already done twice this session for Support heading-only TipTap rich text blocks #6240Add defaultTextBlockStyles option to createTipTapRichTextBlock #6366 and main→cms-admin: Fix invalid DOM nesting in textBlockStyles node views #6363/cms-admin: Don't insert a trailing paragraph after a heading #6364)
  2. Switch this PR's base to main in GitHub (or verify GitHub already auto-retargeted it after the base branch was deleted — still re-check the diff either way, since a squash-merge rewrites commit SHAs)
  3. Re-verify tsc/eslint/the Storybook story after the rebase

Test plan

🤖 Generated with Claude Code

The text block style dropdown was the only way to apply a style like a
large "Display" heading variant, even for blocks where that style is
really a distinct, editor-facing block type in its own right (some
Draft.js RTEs had exactly this: a "display" block type sitting above
"header-one", both rendering as <h1>). That produced two dropdowns
where the legacy block had one, and left the style dropdown showing
only "Default"/"Heading N" for every other heading level.

A textBlockStyles entry with isTextBlockType: true now shows up as its
own entry in the text block type dropdown instead, right above the
plain heading level entry it shares a tag with. Picking that plain
entry, or any other tag, always clears the style, so it can't linger
as a stale value. Requires appliesTo to name exactly one tag, and that
tag can't also carry a defaultTextBlockStyles entry, since the two
would fight over what "no explicit style" means for it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant