-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Moving atomic blocks #551
Moving atomic blocks #551
Conversation
- Just use one function called moveAtomicBlock instead of three - Introduce DraftInsertionType for determining if a fragment shall replace another fragment, or if it shall be inserted before or after another fragment
|
||
var blockMap = contentState.getBlockMap(); | ||
var blockBefore = blockMap.toSeq().takeUntil(v => v === targetBlock).last(); | ||
var blockAfter = blockMap.toSeq().skipUntil(v => v === targetBlock).skip(1).first(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const targetKey = targetBlock.getKey();
const blockBefore = contentState.getBlockBefore(targetKey);
const blockAfter = contentState.getBlockAfter(targetKey);
Hey, any updates on this? |
invariant( | ||
insertionMode !== 'replace', | ||
'Replacing blocks is not supported.' | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it included in the enum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replace is needed in AtomicBlockUtils but not here. Actually i could just implement replace here as well...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually i am not really sure if i should implement the support for "replace" here, since at the moment there is no use case for it.
Actual use case:
- in "moveBlockInContentState" the insertionMode can be "before" or "after"
- in "AtomicBlockUtils" the insertionMode can be "before", "after" or "replace"
So i see 3 solutions:
- implement "replace" in "moveBlockInContentState" even if there is no use case at the moment
- implement 2 different types for "insertionMode", one to use in "moveBlockInContentState" and one to use in "AtomicBlockUtils"
- we just leave it as it is at the moment
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to just leave it as it is at the moment. It makes completely sense in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds fine.
One question around the |
Is there any chance this will get merged soon? dragging atomic blocks seem an important feature |
I'm interesting in the working drag and drop demo, or complete d&d support in draft-js. Moving a block can be easily done with the OrderedMap APIs. |
Sorry for the extremely long wait. Let's go ahead with this. :) |
* Implemented moveAtomicBlockBefore and moveAtomicBlockAfter in AtomicBlockUtils * Renamed EditorChangeType 'change-fragment' to 'move-block' and added to docs * Changed interface for moving atomic blocks: - Just use one function called moveAtomicBlock instead of three - Introduce DraftInsertionType for determining if a fragment shall replace another fragment, or if it shall be inserted before or after another fragment * Using ES6 variable declaration and getStart/EndKey instead of getAnchor/FocusKey
* Implemented moveAtomicBlockBefore and moveAtomicBlockAfter in AtomicBlockUtils * Renamed EditorChangeType 'change-fragment' to 'move-block' and added to docs * Changed interface for moving atomic blocks: - Just use one function called moveAtomicBlock instead of three - Introduce DraftInsertionType for determining if a fragment shall replace another fragment, or if it shall be inserted before or after another fragment * Using ES6 variable declaration and getStart/EndKey instead of getAnchor/FocusKey
To be able to drag and drop atomic blocks around within the editor, it is necessary to have a way to move them within the blockMap. To achieve this goal, this pull request adds the function moveAtomicBlock to AtomicBlockUtils.
This is a copy of #502 since i've mistakenly deleted the pull request branch of that one. Sorry.