Define the TipTap block's text block styles inside the text blocks

[VPS-Andreas]

A text block style had to be configured in two places: globally in textBlockStyles, and again through an appliesTo listing the text block types it was allowed for. Which styles a text block offers could only be read by scanning every style's appliesTo, and two text blocks sharing a tag could not be told apart at all.

A text block now carries its style definitions directly, and textBlockStyles is gone:

const headlineStyles: TipTapTextBlockStyle[] = [
    { name: "headline300", label: "Headline 300", element: (props, Tag) => <Tag {...props} /> },
    { name: "headline400", label: "Headline 400", element: (props, Tag) => <Tag {...props} /> },
];

createTipTapRichTextBlock({
    textBlocks: [
        { name: "heading-1", label: "Heading 1", tag: "h1", styles: headlineStyles },
        { name: "heading-2", label: "Heading 2", tag: "h2", styles: headlineStyles },
        { name: "display", label: "Display", tag: "h1", element: (props, Tag) => <Tag style={{ fontSize: 64 }} {...props} /> },
    ],
    orderedList: { styles: copyStyles },
});

Text blocks that offer the same style share its definition, which makes the shared set explicit instead of implying it through repeated names. A style's element receives the tag of the text block it is applied to, so one definition works for several tags. A text block that needs no style choice carries its own element instead of styles; the two exclude each other in the types, so a text block either offers a choice or renders one way, and the styling select is only shown where there is something to choose. Lists take the same shape instead of appliesTo: ["ordered-list", "unordered-list"].

The stored format is unchanged — a style is still identified by its name in textBlockStyle — so no migration is needed.

Second of four stacked pull requests, on top of #6382; #6384 adds defaultStyle, #6385 splits the block's Storybook stories by topic.

Example

The unit tests in createTipTapRichTextBlock.test.ts/.test.tsx, and in Storybook:

• Text Block Styles
• Text Block Style Interactions
• List Text Block Styles
• Text Block Element

Session: https://claude.ai/code/session_f3c6ad37-c68b-4187-85b6-2abe5aa95c35

[VPS-Obi]

We'll review this once #6382 (which is likely to change) has been merged.

[VPS-Obi]

Out of scope: Now that text block styles live inside text blocks, it's odd that inline styles specific to a text block don't. We could consider moving them into the text blocks config in a follow-up PR.

[VPS-Andreas]

Agreed, and worth doing - appliesTo is the last place where something is tied to a text block from the outside. A follow-up, not this stack, which is four pull requests deep already.

One thing that makes it more than a move of the same shape: an inline style is a mark, not a node attribute. A mark spans a selection and survives a type switch, so a text block can end up carrying one it doesn't offer - the case we just had to handle for textBlockStyle. And the API validates appliesTo (containsInvalidInlineStyleMarks), so content that is fine today can become invalid. Both are solvable, but it needs a decision on what happens to a mark whose text block no longer offers it, rather than only moving the configuration.

[VPS-Obi]

Okay, seems better to leave it like this.