Unfortunately I won’t be able to make it to the development meeting so I’m sharing a few thoughts here:
- Can’t wait for table support!
- Regarding library splitting, I commented on the other thread RFC: Splitting the library into packages
- I haven’t run into any performance problems yet, but setting up benchmarks and regression tests sounds like a good idea to keep it that way going forward
Regarding widgets I can think of the following possible requirements:
- The way a widget/control is rendered should be up to the user (as with menus)
- I could imagine rendering overlays which need to keep their positions in sync with the underlying node (e.g. rendering the controls of a node at the right side of the editor at the height of the node)
- When handling events of a widget (e.g. click on a control), their should be a way to easily get the corresponding node position (this will probably often be used to update the node attributes using
setNodeType)
Something else that I’m interested in, which could potentially be achieved using widgets depending on the implementation:
- Being able to render a handle for a node to allow drag and drop operations via that handle. An example would be rendering a handle to the left of a paragraph when hovering over the paragraph and allowing the paragraph to be dragged and dropped to another position in the document using that handle.
- A similar use case would be to select a node by clicking on such a handle.
I hope this helps!