wip: custom blocks typing and API

[YousefED]

I'm curious what you think if this approach. I think this direction will make it possible to register custom blocks while keeping a strongly typed API.

This PR does:

• refactor of registration of built-in block types.
• makes it possible to have a strongly typed BlockNoteEditor which API matches the Blocks that have been defined. This will make it possible to add support for custom blocks, while keeping a strongly typed API
• As part of this, globalProps and blockProps have been removed, because they should be dynamically configurable as well (based on the "registered blocks" in the editor).

TODO:

• make it compile (nodeToBlock, etc)
• use the new BlockSpec types instead of globalProps / blockProps
• how to handle markdown / html
• design + implement custom block interface
• test / add tests
• ...

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
blocknote-website	❌ Failed (Inspect)			Apr 21, 2023 3:05pm

[dukesx]

Looks promising but don't forget to add support for "react render", a function that tiptap exposes so that we can render react components directly inside Tiptap.

[KashifAhmed]

Great feature, when it will be avail for use 🙂

[dukesx]

@YousefED consider removing renderToHTML and renderToMarkdown since the nature of block cannot be determined. For sematic elements its understood but what about custom components ? they cannot be determined thus it will only consume time but end with nothing and asking dev to provide a whole suite of mark up for their custom component is not the "react" way of doing things. For Vanilla devs, there are far more choices like Editor.js to choose from.

[chrisvasey]

Probably the part of this package I am most excited about 🙏

[YousefED]

superseded by #191

Thanks all for the input!