Skip to content

feat: per-style schema restrictions#2458

Open
rexxars wants to merge 11 commits into
mainfrom
feat/per-style-schema-restrictions
Open

feat: per-style schema restrictions#2458
rexxars wants to merge 11 commits into
mainfrom
feat/per-style-schema-restrictions

Conversation

@rexxars
Copy link
Copy Markdown
Member

@rexxars rexxars commented Apr 3, 2026

This one might need a bit of discussion, but here goes:

Goal: Allow style definitions in the PTE schema to restrict which decorators, annotations, lists, and inline objects are allowed per block style, so the editor core (toolbar, paste, keyboard shortcuts, normalization) automatically respects these restrictions. This is to for instance disallow links in titles, but allow it in regular text paragraphs.

Architecture: Extend StyleDefinition and StyleSchemaType with optional decorators, annotations, lists, and inlineObjects override arrays. Add a getStyleFeatures(schema, styleName) helper that returns the effective feature set for a style (the style’s overrides if present, else the top-level schema arrays). Update all schema consumption points to use this helper when the block style is known. The toolbar already has disable/enable infrastructure - wire the availability listener to check per-style restrictions.

rexxars and others added 11 commits April 3, 2026 11:01
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… during normalization

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ions

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ir feature

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…trictions

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add Gherkin feature file and browser test for per-style decorator
restrictions. Also fix style-change normalization: when the `style`
property changes on a text block, dirty the child span paths so the
normalizer can strip marks that the new style disallows.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@rexxars rexxars requested a review from christianhg April 3, 2026 20:59
@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Apr 3, 2026

⚠️ No Changeset found

Latest commit: 882bdc6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@vercel
Copy link
Copy Markdown

vercel Bot commented Apr 3, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
portable-text-editor-documentation Ready Ready Preview, Comment Apr 3, 2026 9:01pm
portable-text-example-basic Ready Ready Preview, Comment Apr 3, 2026 9:01pm
portable-text-playground Ready Ready Preview, Comment Apr 3, 2026 9:01pm

Request Review

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 3, 2026

📦 Bundle Stats — @portabletext/editor

Compared against main (ef6dabae)

@portabletext/editor

Metric Value vs main (ef6daba)
Internal (raw) 749.7 KB +2.6 KB, +0.4%
Internal (gzip) 141.3 KB +544 B, +0.4%
Bundled (raw) 1.34 MB +3.6 KB, +0.3%
Bundled (gzip) 301.9 KB +765 B, +0.2%
Import time 84ms +2ms, +2.1%

@portabletext/editor/behaviors

Metric Value vs main (ef6daba)
Internal (raw) 467 B -
Internal (gzip) 207 B -
Bundled (raw) 424 B -
Bundled (gzip) 171 B -
Import time 2ms -0ms, -0.9%

@portabletext/editor/plugins

Metric Value vs main (ef6daba)
Internal (raw) 2.5 KB -
Internal (gzip) 910 B -
Bundled (raw) 2.3 KB -
Bundled (gzip) 839 B -
Import time 7ms +0ms, +1.1%

@portabletext/editor/selectors

Metric Value vs main (ef6daba)
Internal (raw) 60.5 KB -
Internal (gzip) 9.5 KB -
Bundled (raw) 56.9 KB -
Bundled (gzip) 8.7 KB -
Import time 6ms -0ms, -1.1%

@portabletext/editor/utils

Metric Value vs main (ef6daba)
Internal (raw) 24.2 KB -
Internal (gzip) 4.7 KB -
Bundled (raw) 22.2 KB -
Bundled (gzip) 4.4 KB -
Import time 5ms -0ms, -0.9%

🗺️ . · ./behaviors · ./plugins · ./selectors · ./utils · Artifacts

Details
  • Import time regressions over 10% are flagged with ⚠️
  • Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

@christianhg
Copy link
Copy Markdown
Member

This looks interesting and relevant and aligns with some of the thoughts I'm having myself:

I'm working on first-class nesting where text 'block's can be children of other blocks to thereby create nested, editable structures. For example, a 'code' block might have an array field that accepts of: [{type: 'block'}].

What I have been thinking about in that regard is how to scope and inherit decorators, annotations, lists and styles, and this PR basically mirrors my thinking:

  1. Explicitly configuring them on a nested block overrides them
  2. Leaving them undefined inherits from the root schema

This means that for a text block in a code block you want to set them all to [] while a text block in a callout might want to inherit annotations and decorators from the root.

One thing I've been thinking about in addition, as part of this work, is if it should be possible to define different types of text blocks to thereby scope schema definitions, even at the editor root. But even if that becomes a thing, top-level per-style schema restrictions feel valuable on their own, solve a real problem without inventing a new concept and work out-of-the box with serializers.

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.

2 participants