And hey again! Another issue/question on the void nodes. It seems from the examples that one can't cut or copy the void nodes by default - that there is no native editor behavior. I was wondering if I could understand how and why it behaves the way it does.
Does it imply that we have to implement custom onCut, onCopy handlers everytime we have void nodes?
Or should the default ones fire with the default behavior - like lets say, in the case of copying a void node from one part of the editor to another?
Thanks!
Hey @oyeanuj good question. It should handle this by default, but because of the way that copying currently works I think it aborts if the selection is collapsed, so it doesn't void nodes. But I'd definitely accept a PR that fixes that!
Okay, I think I can tackle that. So, just to be sure, would the desired solution be to abort only if selection is collapsed AND NOT in a void node?
I did find this line that was responsible here, so I'll play around and test it.
Any progress on this @oyeanuj ? I need a solution to the same problem. Tell me if I can assist.
@skogsmaskin Apologies, I haven't had the chance to look into it, but will in the next day or two. Will post an update soon, assuming my comment above is the desired solution.
That solution sounds good to me. Anything that gets it to function for all types of nodes for internal copies sounds good to me, mimicking the native behavior as much as possible.
A quick update and question for @ianstormtaylor:
So, it has turned out to be more complicated than I thought (as always). But tracing thru functions, it seems like the root cause seems to be that state.fragment.nodes is empty when copying from a void node. Because of this, even if I comment out the line mentioned in the previous comment, there is nothing to copy.
state.fragment.nodes being empty seems to happen because document.getFragmentAtNode returns early if the selection is collapsed.
It seems like we could introduce a check here to make exception if any of the ancestors are void nodes, but it seems like a bigger change than I anticipated since this is also part of the documented API.
So, question to @ianstormtaylor - what would you suggest? Does that change sound okay to you?
I think getFragmentAtRange actually shouldn't return early, that's my mistake. Instead it should simply return the tree but with no text content, as you might expect. Such that you can get a fragment containing a void node, or even a fragment that happens to be an empty paragraph. I'd gladly accept a PR that makes that work.
Relevant update: The above comment has been addressed (and merged). This is the PR to kick off fixing this issue - https://github.com/ianstormtaylor/slate/pull/676
Most helpful comment
Relevant update: The above comment has been addressed (and merged). This is the PR to kick off fixing this issue - https://github.com/ianstormtaylor/slate/pull/676