feat: position storage

[nperez0111]

This is still in progress, the idea here is to make a class that can be used for keeping track of positions in the editor across collaborative or single user transactions.

This would be useful not only for the suggestions plugin, but for anything that would need to hold onto a position across transactions.

I still am working through setting up the tests to prove that it is able to keep track of those positions, but I had it preliminarily working for the suggestion plugin at one point, but then decided to solve this in a more generic way.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
blocknote	✅ Ready (Inspect)	Visit Preview	Mar 31, 2025 4:37pm
blocknote-website	✅ Ready (Inspect)	Visit Preview	Mar 31, 2025 4:37pm

[nperez0111]

Let's have a discussion on this.

In general, here is what I'm thinking:

• The editor instance is the main thing passed around and is essentially a god object
• configuration is primarily done through the editor instance, making it the most convenient place to store and retrieve references to the current config

I think what we need to be aiming for here instead is a de-coupled approach like prosekit, where the editor doesn't "have" these sorts of values, it can execute commands to move between states, but the values of these are stored elsewhere (like context).

Given that we don't have a good solution for state management at the moment, I propose here to just sweep things under the rug for a little while, and put them under an ~internal property. Using ~ makes it both cumbersome (read intentional) and shows the value last in TS autocomplete idea from standard-schema.

For configuration, I think that if the schema was defined separately, it would be much easier to configure things like tables and codeBlocks. For example:

import { defaultSchema, tableBlock } from '@blocknote/core/schema';|
import { BlockNoteEditor } from '@blocknote/core';

const editor = BlockNoteEditor.create({
  schema: defaultSchema.replace('table', tableBlock.configure({ option: true })
})

// editor.schema.table.config.option === true

Obviously, there are a lot of different ways to do it, but the point is that the editor doesn't really have to know about this.

What about all of the prosemirror plugins? It could maybe be something like:

import { BlockNoteEditor, BlockNoteExtension, getDefaultExtensions } from '@blocknote/core';

const editor = BlockNoteEditor.create({
  extensions: getDefaultExtensions.remove(['tables']).add({ myExt: BlockNoteExtension.create({ name: 'myExt', plugin: new Plugin() }) })
})

// editor.extensions.myExt.plugin

Again, different approaches here too

[nperez0111]

An alternative to this, would be to have a prosemirror plugin that gets these transactions between state updates. Perhaps that is preferable?