描述
I think this is a bug, because this does not seem normal for any reason.
When the anchor edge of a selection which needs to be removed in code is the first block of the blockMap, it doesn't get removed from blockMap upon .removeRange(). In my case, there is an atomic block dangling as the first block (which could be unstyled too), but I don't see a reason why it should be there. My use case is one of repositioning sections on a document.
This behavior does not happen for when the range is anywhere else in the editor.
Code is pretty straightforward, nothing special needed to reproduce this:
...
// blocksToMove is an Array of ContentBlocks that constitute a section of the doc. Think of it as one header to the next header.
var startingKey = currentContent.getKeyBefore(fromKey);
var toMoveSelection = SelectionState.createEmpty(blocksToMove[blocksToMove.length - 1].get('key')).set( 'anchorKey', startingKey || fromKey);
// 'backward' doesn't help either.
var newContentState = Modifier.removeRange(
currentContent, toMoveSelection, 'forward'
);
...
// Yes I know I could use const and lets.
When I observe the blockMap right after these operations, if starting key was for the first block, the block still remains in the map at the 0th (or first() position). Not the case when my range does not have the first block as its anchor.
Working with 0.5.0.