fix: Fixed with pasting a void block in a paragraph middle path #5937
Conversation
|
|
My concern with this is it might make it harder to modify the behaviour of pasting of void blocks at locations where these blocks are not valid. List items example
Generally, no block elements other than LI, LIC, OL and UL are allowed anywhere in the list structure. It looks like with this PR, pasting in the middle of the text of a LIC will cause that LIC to be split and the image inserted between the two LICs.
A normalizer might clean this up by removing the image or relocating it to before or after the list, but this would still leave us with two LICs in the same LI, which isn't valid. Existing normalizers might handle the two-LICs case by splitting the LI.
But this doesn't make sense since nothing was actually pasted at the point where the LIs were split. Normalizers might instead handle the two-LICs case by re-merging the LICs, but this might require making additional code changes, such as when splitting a LIC intentionally using the enter key or when pasting text containing multiple lines. Conclusion |
Indeed, this behavior might occur, but I understand that in this method, we should focus solely on the behavior of block splitting and connection during content insertion, keeping his role as singular as possible. The normalizer process should be handled by the corresponding plugin implementation, or we could add a parameter in options to let users control whether to split paragraphs instead of accommodating the boundary behavior of different types of tags in this method. Or maybe I've misunderstood insertFragment. If you have other ideas for how to do this, I'd love to hear your suggestions. |
|
I suppose list plugins could override |
This is indeed a solution, but it requires the user to handle the corresponding plugins themselves. If this change can be merged, all we can do is indicate the impact of this change in the changelog |
|
I don't think there's any way of handling this in the core One thing we could do is add options to However, for this to be useful, the override code would also need a way of determining which exact block the nodes will be inserted into. The logic for determining this is non-trivial, since it involves This is quite a lot of logic for override code to duplicate, so maybe instead the const { insertFragment } = editor
editor.insertFragment = (fragment, options) => {
const { filter = () => true } = options
const filteredNodes: Node[] = []
insertFragment(fragment, {
...options,
filter: (node, filterOptions) => {
if (!filter(node, filterOptions)) return false
// Prevent splitting a LIC to insert a void block
if (
filterOptions.blockEntry[0].type === 'lic' &&
Element.isElement(node) &&
Editor.isBlock(node) &&
Editor.isVoid(node)
) {
filteredNodes.push(node)
return false
}
return true
},
})
// Insert filteredNodes before or after the list
// ...
}I think it's reasonable to expect list plugins to do this, but as you say we should describe this in the changeset. |
2 participants
Description
Inserting a void block (such as an image) in the middle of a paragraph would incorrectly insert it before or after the paragraph. This change will cause it to be inserted at the cursor or selection position.
Issue
Fixes: (link to issue)
Example
befor:
befor.mp4
after:
after.mp4
Context
If your change is non-trivial, please include a description of how the new logic works, and why you decided to solve it the way you did. (This is incredibly helpful so that reviewers don't have to guess your intentions based on the code, and without it your pull request will likely not be reviewed as quickly.)
Checks
yarn test.yarn lint. (Fix errors withyarn fix.)yarn start.)yarn changeset add.)