I am hoping to determine if I am thinking about how to handle custom paste behavior in the way it was intended. Currently, I have utilized the handlePaste off of the props of a plugin specific to the thing I am trying to work with (in our case table nodes) which works just fine. However, I am working on an editor which is meant to be extensible by whoever uses it and thus could add their own behavior for pasting different things if they wanted that would play nice with the built in paste behavior. As I investigate this though I have noticed that if there are multiple “handlePastes” set up in a chainlike fashion whether form the editorProps or from plugins we don’t seem to have a way of knowing in one handlePaste if another handlePaste has changed the view before it. I understand you could (and maybe have to) just return true from a handlePaste when it does something, but then this breaks the chain. In my head I am thinking of a use case in which each part of this handlePaste chain could be for a different node type and thus each would need to fire, but as I write this I feel like it just isn’t possible to do something like this in the current architecture. Does this ring true for anyone else?
Perhaps one could create a prop that a consumer could pass in an array/object of keys (nodeTypes) and values being callback functions which need something like the event, slice, view, and perhaps transaction to be built upon with each nodeType. Then the editorView could take this array and run through each callback function passing this information from one to the next until completion and dispatch the resulting transaction?
What kind of things are your paste handlers doing? If they are actually handling the paste (modifying the editor state for it), then it only makes sense for one of them to take effect, and returning true makes sense. If they just need to affect the way the pasted content is read, using transformPasted or transformPastedHTML might be more appropriate.
Thanks for the response Marjin! The paste handler I have written handles the logic of pasting merged cells onto a table by doing things like expanding the size of the table if the rect of cells is pasted somewhere in the table that will cause the pasted cells to overflow. Another use case it handles is that if you have a set of cells selected it will only paste a subset of the cells from the clipboard. Perhaps I am overthinking this, but the problem I foresee is that if my handler works for pasting cells into a table and I return true then if a consumer in theory has some “special” node that needs to be handled differently on paste and resides in a table cell then it wouldn’t fire because mine would trump it. I don’t have a specific use case in mind, but am just trying to future proof as well as I can. It may be the case that the parseDOM/toDOM logic would handle anything with the “special” node though?
Sounds like you really need handlePaste for this, so probably the best thing to do is to be as strict as you can about situations where your handler fires (if something is pasted within a cell that requires no table-specific handling, for example, you’d return false) and hope for the best.
That makes sense. So overall handlePaste sounds like the way to go, but we will just need some airstrike precision for when they actually do their thing. I appreciate the insight, thank you!
