-
-
Notifications
You must be signed in to change notification settings - Fork 556
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
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
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. |
Great feature, when it will be avail for use 🙂 |
@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. |
Probably the part of this package I am most excited about 🙏 |
superseded by #191 Thanks all for the input! |
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:
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 APIglobalProps
andblockProps
have been removed, because they should be dynamically configurable as well (based on the "registered blocks" in the editor).TODO:
globalProps
/blockProps