Modifier.replaceWithFragment() loses block type if fragment size === 1

[tomkelsey]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Modifier.replaceWithFragment() loses block type if fragment size === 1

What is the expected behavior?

Modifier.replaceWithFragment() persists block type

Other

I don't know if there's a wider reason for this that I haven't understood yet but

https://github.com/facebook/draft-js/blob/c1150a729080d04014551d1c78292cb05da7cf1b/src/model/transaction/insertFragmentIntoContentState.js#L61

I believe there should be an extra line after data: pastedBlock.getData() with type: pastedBlock.getType() as this would seemingly resolve the issue?

[colinjeanne]

Consider this: suppose I have a block whose type is unordered-list-item and whose text is Hello meh world. I select meh and paste great over it. If I copied great from somewhere outside of Draft then the fragment's block type is likely going to be unstyled.

If we use the fragment's block type in this case then the result of the paste is that the block's text is changed to Hello great world and the block is changed so that it's no longer a list.

That, I think, would be an unpleasant experience.

[tomkelsey]

Thanks for the explanation @colinjeanne - that makes sense as to why it is the way it is then!

I'm afraid I'm not familiar enough with DraftJS' workings to even begin to suggest something that would work in both instances. By that, I mean I am currently attempting to copy and paste an image. I parse the HTML in handlePastedText and set the block type of the image to being atomic but when replacing the current selection with it using replaceWithFragment it loses it's block type and doesn't function as intended.

[kaylee42]

I recognize that the current draft behavior is desirable in the majority of circumstances; however, it would be nice to be able to manually override the current behavior of replaceWithFragment to insert only a single block to handle cases like the one @tomkelsey describes above.

I have a custom block insertion util based on draft's AtomicBlockUtils (with variations to be able to insert multiple custom block types). The AtomicBlockUtils insertion function always includes an empty, unstyled divider block, and right now that's why my insertion function does as well.

However, it would be really nice not to wind up with a bunch of extra empty blocks getting inserted into documents. I'm wondering if it would be possible to pass a flag to replaceWithModifier similar to the one in updateEntityDataInContentState which would indicate whether or not the block should override the type of the pre-existing block. That way you would have to be really intentional about overriding the block type, and still allow the flexibility of inserting a single custom block without a divider block when needed.

[hejtmii]

Hi @colinjeanne, do you have any explanation for what scenario is the following code (mentioned ealier by @tomkelsey) in there?

data: pastedBlock.getData(),

Based on your explanation, it should either keep the block data of the existing block, or at least merge the original and new block data. Is that a bug or is there a logical explanation why type is not applied from inserted fragment but data is?

[colinjeanne]

@kenticomartinh, I don't have a good explanation for that. It seems to me that it should use the target block's data for consistency rather than the pasted block's data. In our own editor where we use block data we end up detecting this case and setting the data explicitly.

The data field is, in particular, difficult to deal with because it is just a generic data store. Draft has no idea what is in it or what the semantics are so merging doesn't seem like a sound option. Even if it merges it would still need to decide whether the target or the pasted block takes precedence when they have different values for the same key.

[xtrinch]

It also seems to me there should be a way to replace the type. Are there any known workarounds for this?