Core Data: Test entity undo reducer. #18642
Conversation
epiqueras
added
[Type] Automated Testing
| lastEdits = {}; | ||
| undoState = undefined; | ||
| expectedUndoState = []; | ||
| expectedUndoState.offset = 0; |
There was a problem hiding this comment.
This is interesting to see in a state, as normally the state should be serialisable. Could you comment on this in the reducer? Why can't it be nested?
There was a problem hiding this comment.
It could be nested. I just followed from the previous iteration and I think I've seen other places where this is done.
I guess we should change it in another PR if we need to serialize it.
| let action = {}; | ||
| if ( args[ 0 ] === 'isUndo' || args[ 0 ] === 'isRedo' ) { | ||
| // We need to "apply" the undo level here and build | ||
| // the action to move the offset. |
There was a problem hiding this comment.
Why does the action need to be build based on the state? Isn't that something that can be done in the reducer?
There was a problem hiding this comment.
Previously we had UNDO and REDO actions.
There was a problem hiding this comment.
Because the editor grabs the undo edit and applies it, the undo reducer just keeps track of the offset.
packages/core-data/src/reducer.js
Outdated
| // Don't update the last edit cache if the new one only has transient edits. | ||
| // Transient edits don't create new levels so updating the cache would make | ||
| // us skip an edit later when creating levels explicitly. | ||
| Object.keys( action.edits ).some( ( key ) => ! action.transientEdits[ key ] ) |
There was a problem hiding this comment.
Is there an e2e test case that could fail without this change?
There was a problem hiding this comment.
No, it's not a flow that happens in the editor, but it could happen with other third party usage.
| transientEdits, | ||
| }; | ||
| action = { | ||
| type: 'EDIT_ENTITY_RECORD', |
There was a problem hiding this comment.
I really liked how the previous history reduces could work with any state and actions. This one seems to handle EDIT_ENTITY_RECORD. Is there any way it could be more abstracted? Cc @aduth.
There was a problem hiding this comment.
What other actions does it need to handle for entities?
I don't think this is how this reducer will look like in the long term, specially after adding support for collaborative editing.
But, for now it gives us a lot of control over details that allow us to meet requirements for things like explicit levels and other nuances that the editor and block editor need. A more generalized abstraction could make that harder.
… of ignoring them.
|
@ellatrix My change to the reducer needed a tweak. I would appreciate another look 😄 |
|
In 3bcddbe, I see changed and added code, but no extra tests. Would it make sense to have tests for this part? |
|
@ellatrix Yeah, but it fixed an e2e test that was failing, so it's already covered. |
epiqueras
force-pushed
the
add/core-data-undo-reducer-unit-tests
branch
from
e817ff6 to
f3ac6ba
Compare
epiqueras
force-pushed
the
add/core-data-undo-reducer-unit-tests
branch
from
f3ac6ba to
05e4845
Compare
Closes #17434
Description
This PR adds unit tests for
core-data's new undo reducer.It also fixes a minor edge case where we were updating a reference to the last edit action even if the new action only contained transient edits. This was causing us to skip/delete an undo level when explicitly marking the last changes as persistent.
How has this been tested?
They are tests 😄
Checklist: