The way valid parent-child relations for node types are
specified was changed. Instead of relying on strings, node
kinds are now objects that specify arbitrary sub-kind
relations. The static kinds property on node types replaced by a
non-static kind property holding such a kind object, and the
contains property is now expected to hold a kind object instead of a
string.
The keybindings for make-paragraph and make-heading were changed. To
make the current textblock a paragraph, you now press Ctrl/Cmd-0, and
to make it a heading, you press Ctrl/Cmd-N, where N is the level of
the heading.
Bug fixes
Copy-pasting between ProseMirror instances is now more robust (the
question of whether the selection cuts through nodes at the start and
end of the fragment is preserved).
Selection management on mobile platforms should now be improved (no
longer unusable, probably still quite buggy).
Fix a problem where reading a change from the DOM was confused by
trailing whitespace in a text block.
Fix a bug in scrolling things into view that would break scrolling of
anything except the whole document.
Don’t render menu dropdown elements unless they actuall have content.
Fix bug that would reset the selection when a
selectionChange event handler
tried to access it.
The selection classes are now properly exported from
the edit module.
In our schema some node types (Heading, BlockQuote) can only be on the top level. Paragraph can be on the top level or under BlockQuote. It worked with 0.3.0; this change doesn’t make it work with 0.4.0. What would be the equivalent?
Looks like
export const NodeKindTop = new NodeKind('ed_toplevel')
const NodeKindTopOrBlock = new NodeKind('ed_toplevel_or_block', NodeKindTop)
NodeKindTopOrBlock.supers[NodeKind.block.id] = true
Though my previous statement is technically correct, the resulting kind still won’t do what its name suggests (and neither did your code) – it’ll create a kind that is a sub-kind of top and block, whereas you probably want one that’s a super-kind of those. I’ve so far solved this by creating a new block kind, making it a sub-kind of top, and subclassing all block node types to use that instead of the built-in block kind. This is a bit of a pain, and I’m currently experimenting with a system where you can also create new kinds by specifying their sub-kinds.
Only issue I see is that in a new paragraph in a blockquote I’m seeing the tooltip for Heading. It’s allowed in the schema BlockQuote contains, but not in Heading kind. I can’t apply it from the tooltip, only see it.
How can I allow Paragraph and Lists to be top level or under BlockQuote, but Heading only top level?
Your code looks good. This’ll be easier in the next version (you won’t have to replace the built-in block type anymore).
I filed issue 219 for the command showing up in the wrong context. To work around that, you could define your own select method for the heading:make command until that is fixed.