Remove synced blocks from lastBlockInserted #52558
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
scruffian
added
[Block] Navigation
|
Size Change: +604 B (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 109384e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5543295053
|
draganescu
reviewed
Jul 12, 2023
| @@ -3328,7 +3328,7 @@ describe( 'state', () => { | |||
| expect( state.clientIds ).toEqual( [ clientIdOne, clientIdTwo ] ); | |||
| } ); | |||
|
|
|||
| it( 'should return client ids of all blocks when inner blocks are replaced with REPLACE_INNER_BLOCKS', () => { | |||
| it( 'should not return client ids of all blocks when inner blocks are replaced with REPLACE_INNER_BLOCKS', () => { | |||
There was a problem hiding this comment.
Can we in any way make this a positive assertion?
There was a problem hiding this comment.
Yes. Put some initial blocks in state. Freeze them. Run the reducer function. Check the blocks in state are the same.
There was a problem hiding this comment.
I've updated the test. Does this look better?
There was a problem hiding this comment.
Yes thank you so much 🙏🏻
draganescu
changed the title
draganescu
approved these changes
Jul 12, 2023
There was a problem hiding this comment.
It is unclear to me if the name of the reducer should be lastManuallyInserted :D in the sense that we want to to give us as close as possible the ID of the last block the user inserted. What the application does in the background should not be counted but also the name is not making this obvious. Maybe the function doc should specify?
However I think this PR is good since it solves the problem it introduced a while ago. No tests or functionality seem to be broken because of this here not is it a foundation aspect of data flow - it's too new.
jffng
reviewed
Jul 12, 2023
@scruffian This is likely the |
Done here: #52604 |
|
I gave this another test by rebasing #52604 against this branch / PR, and it fixed the above issue. Nice work! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Fixes #51713.
How?
Removes REPLACE_INNER_BLOCKS from the condition under which we determine that a block has been inserted into the canvas.
useBlockSynccallsreplaceInnerBlocks, when it's trying to sync the controlled blocks state:gutenberg/packages/block-editor/src/components/provider/use-block-sync.js
Line 127 in de71547
Since #46885, this ends up setting the state for the last inserted block in the reducer:
gutenberg/packages/block-editor/src/store/reducer.js
Line 1858 in de71547
This means that when a controlled block is synced, the app considers all of these blocks to be "last inserted blocks". However the user would not consider these blocks to have been "last inserted".
This causes issues like #51713, because we keep on thinking that the search block has been inserted again and resetting the attributes.
Testing Instructions