Skip to content

wip: custom blocks typing and API #164

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

YousefED
Copy link
Collaborator

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
Copy link

vercel bot commented Apr 12, 2023

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
Copy link

dukesx commented Apr 25, 2023

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
Copy link

KashifAhmed commented Apr 27, 2023

Great feature, when it will be avail for use 🙂

@dukesx
Copy link

dukesx commented Apr 27, 2023

@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
Copy link

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

@YousefED
Copy link
Collaborator Author

superseded by #191

Thanks all for the input!

@YousefED YousefED closed this May 30, 2023
@YousefED YousefED mentioned this pull request May 31, 2023
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants