Props complexity for custom blocks

[GuillaumeOnepilot]

Is your feature request related to a problem? Please describe. I currently try to benchmark BlockNote for my use cases, including complex custom blocks, currently, the type system is only allowing props to be string, number or boolean, and for example, my use case is a block that have an array of object containing a title and some text, each element of the array is a possible display of the block, this doesn't look possible (or with many @ts-ignore?) maybe I'm missing something or do something wrong.

Describe the solution you'd like Being able to have complex props types

Describe alternatives you've considered Encode my objects/array to JSON, but it's messy and really not great

Additional context

[matthewlipski]

Props only taking primitive types is indeed a design choice that we've made, though it's largely due to copy/paste actually. Basically, by rendering out a block's type and props to HTML attributes, we can recreate the block without having to implement custom parsing logic for it, meaning custom blocks can be copied and pasted within BlockNote, without consumers having to explicitly tell BlockNote how certain HTML elements should be parsed.

The issue with using arrays/JSON as props is that now these also have to be rendered out to HTML attributes in order to keep this working, which as you can imagine, makes the DOM quite cluttered.

While we're still looking for good ways to improve this, you can still make it work now. Let's say you want to add a prop to a custom block, the prop is called items, and it should take an array. Instead, you add an itemsId prop and make it a string. If you assign a unique ID each time, you can then use it to reference fields in a map outside of BlockNote, which store the array that you actually want to use. It's not ideal since you basically have to deal with a prop state that's outside BlockNote, but it should work fine aside from that.

[GuillaumeOnepilot]

This makes some sense, but you could also allow complex props and require the implementation of the parse and the toExternalHTML ? Your solution could partly work for my case as I use Redux to store my data, but considering my current editor contains a lot of custom blocks, this would add a transformation step before passing data to the editor (not counting the migration to the new format)😐

[matthewlipski]

True, it's still something we'll have to discuss but a good suggestio imo, @YousefED thoughts on this?

[GuillaumeOnepilot]

I don't know if it could help, but some editors like Notion or EditorJs (the editor that I currently use) use a JSON representation of the blocks inside the clipboard.

This solution could be interesting for browser that support it and for copy and pasting between BlockNote editors. Unfortunately, it's not supported by Firefox (and maybe others?), I think.