remove schema restriction on texts around inlines

Do you want to request a feature or report a bug?

Debt.

What’s the current behavior?

Right now the core schema will always ensure that inline nodes are surrounded by text nodes. This was to ensure that when inserting text you can always insert on either side of the inline node.

However it’s a bit of an intense restriction, and results in the data model itself having extra “junk” in it.

What’s the expected behavior?

Instead, I think we may be able to solve this with editor queries. With a query like…

const point = editor.resolveInsertionPoint(point)

It could ensure that a text node exists to type into if we’re at the leading/trailing edge of an inline node. This would also be an override point for folks who want to implement “sticky” inlines.

(Slightly different than an editor.getInsertionPoint which you wouldn’t expect to change the document at all. And a reason for #2861 to reduce the arbitrary distinction between queries and commands.)

That way the restriction can be editor-level instead of data-level, resulting in more flexibility for people with advanced use cases.

[ianstormtaylor]

I completely agree, I want the getInsertionPoint behavior to be overridable too. Another issue for it sounds good just to keep track.

As for data model that makes sense. I think my use case is probably pretty far out there in terms of architecture, so it might not make as much sense. (Although I think that’s generally a good thing for making sure the framework is well designed!)

Can you give me an example of your deserialization troubles? Just curious to see if there are ways to ease them.

Thanks!

[ianstormtaylor]

Ah okay, I didn’t realize it was all inside the normalization logic where the problems are. Having the multi-pass solution for performance sounds like it could be promising. And once we’ve dropped Immutable that will make it a bit less costly too hopefully.