fix: BlockTypeSelect item filtering based on schema

[matthewlipski]

Summary

This PR makes the BlockTypeSelect filter its default items based on whether they're allowed in the schema, same as how the slash menu already works.

Rationale

You can configure things like allowed levels for the default heading block, but the BlockTypeSelect won't reflect this change.

Changes

• Refactored blockTypeSelectItems to getDefaultBlockTypeSelectItems.
• Fixed typo in default block configuration example.

Impact

N/A

Testing

Not sure how feasible testing smth like this is atm. We'd have to set up component testing across all of the examples.

Screenshots/Video

N/A

Checklist

• Code follows the project's coding standards.
• Unit tests covering the new feature have been added.
• All existing tests pass.
• The documentation has been updated to reflect the new feature

Additional Notes

[vercel]

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

Project	Deployment	Preview	Updated (UTC)
blocknote	Error		Oct 27, 2025 1:11pm
blocknote-website	Error		Oct 27, 2025 1:11pm

[matthewlipski]

@nperez0111 sort of related but only tangentially - I noticed that switching to the default block configuration example and then back to any other one doesn't revert the heading prop schema back to having 6 levels. It's stuck having the 3 levels.

I traced the issue back to BlockNoteViewComponent, somehow the editor passed to it doesn't have the correct heading prop values. This is especially weird because changing the block schema in e.g. the custom alert example and switching to the default schema example correctly updates to only have the default blocks and no alert.

Could you take a look at it?

[pkg-pr-new]

Open in StackBlitz

@blocknote/ariakit

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/ariakit@2112

@blocknote/code-block

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/code-block@2112

@blocknote/core

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/core@2112

@blocknote/mantine

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/mantine@2112

@blocknote/react

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/react@2112

@blocknote/server-util

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/server-util@2112

@blocknote/shadcn

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/shadcn@2112

@blocknote/xl-ai

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-ai@2112

@blocknote/xl-docx-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-docx-exporter@2112

@blocknote/xl-email-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-email-exporter@2112

@blocknote/xl-multi-column

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-multi-column@2112

@blocknote/xl-odt-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-odt-exporter@2112

@blocknote/xl-pdf-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-pdf-exporter@2112

commit: 5118467

[nperez0111]

Looking at this with fresh eyes again, and I'm thinking that the editorHasBlockWithType type guards should maybe be gated within the BlockTypeSelect component's filteredItems instead. Take this for example:

{
      name: editor.dictionary.slash_menu.quote.title,
      type: "quote",
      icon: RiQuoteText,
      isSelected: (block) => block.type === "quote",
    }

Like, can't we know exactly what block this is trying to select based on the type & optional props object? This would allow us to filter the list down & cut down on the type guards needed.

Maybe this is over complicating it, but having a filter for this sort of thing is sort of useful generically, like in the slash menu, block type select & other places surely