Record selection changes in history (undo)#16428
Conversation
41f4892 to
7315f25
Compare
6e691f5 to
a95e3f0
Compare
32d03bf to
ee24ec0
Compare
f5d17c1 to
0b74a1d
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
0b74a1d to
9886d9f
Compare
|
Phew, this passed now! It was not obvious from the errors what the cause was, but apparently it was resetting the selection when the provider didn't provide any selection, which is the case for previews. :) |
|
So this is again ready for a final review. |
epiqueras
left a comment
There was a problem hiding this comment.
Since #16932 was merged, we'll need to take a different approach here.
I think it should be pretty easy to make the selection a transient edit of the post entity just like .blocks:
This makes them part of undo behavior, but not considered for change detection or persistence.
We can probably still keep all of the other changes that simplify the reducer.
|
@epiqueras Thanks for letting me know. What's the best place I can learn about the changes? I'll have a look through the code changes soon. |
|
Closing in favour of #17824. |
Description
Creates selection reducers in
core/editorto track selection within thewithHistoryreducer.I've also split
isSelectionEnabled,isMultiSelecting, andinitialPositionout of theblockSelection, as these are not tied to the selection state. Since the reducer then didn't contain anything but the start and end of the selection, I flattened the structure tostate.selectionStartandstate.selectionEnd. The reducers ended up being much simpler.The following gif shows the result after two times undo:
How has this been tested?
Screenshots
Types of changes
Checklist: