Block Editor: Consider received blocks state change as ignored #14916

aduth · 2019-04-10T20:01:59Z

This pull request seeks to resolve an issue where any fetch of reusable blocks (selecting a paragraph, using inserter, editing a post containing reusable block) would cause the post to immediately become "dirty" (prompt the user about unsaved changes when navigating away) and would immediately add an undo history level.

The changes here effectively better align to behavior of RECEIVE_BLOCKS prior to #13088 . As of #13088, we considered RECEIVE_BLOCKS as "non-persistent" which helped for avoiding to create undo levels (except when it's the first action of a session), but did not consider that received blocks should be entirely ignored in consideration of change detection (as it was implemented before #13088).

Testing Instructions:

Repeat Steps to Reproduce from #14910 and #14766, verifying expected results.

Ensure unit tests pass:

npm run test-unit packages/e2e-tests/specs/change-detection.test.js

Ensure end-to-end tests pass:

npm run build && npm run test-e2e packages/e2e-tests/specs/change-detection.test.js

…istentChange

nerrad · 2019-04-11T12:09:53Z

docs/designers-developers/developers/data/data-core-block-editor.md

@@ -775,6 +775,20 @@ via its `onChange` callback, in addition to `onInput`.

 Whether the most recent block change was persistent.

+### __unstableIsLastBlockChangeIgnored


hmm... I didn't think __unstable or __experimental was supposed to show up in docs?

hmm... I didn't think __unstable or __experimental was supposed to show up in docs?

It caught me off guard as well. I think they may only be omitted in documentation generated by the docgen tool. The data modules documentation is a separate process. It should be improved (I'll create a follow-up task).

nerrad · 2019-04-11T12:19:19Z

packages/block-editor/src/store/reducer.js

+	 */
+	const IGNORED_ACTION_TYPES = new Set( [
+		'RECEIVE_BLOCKS',
+	] );


so for now is this just going to be a hardcoded list? Would there be value in being able to customize what action types are ignored? Eg. being able to call it like this:

withIgnoredBlockChange( [ 'RECEIVE_BLOCKS' ] )

If so, and that's useful, then the name of the HOC could maybe be changed to withIgnoredActionChange?

Re 'RECEIVE_BLOCKS being ignored, does that mean we expect change to be ignored for any block addition to the editor (and I'm assuming changes would get picked up when there is content added to the block?)

Re 'RECEIVE_BLOCKS being ignored, does that mean we expect change to be ignored for any block addition to the editor (and I'm assuming changes would get picked up when there is content added to the block?)

So, considering all of the above: Our use of RECEIVE_BLOCKS is and always has been exclusively a way to get blocks data for reusable blocks into state so they can be treated the same as any other content block by selectors such as getBlock, etc. But they're not part of the actual content. Regular user workflows to add blocks will go through INSERT_BLOCKS and friends.

Long-term then: RECEIVE_BLOCKS shouldn't be ignored, this list won't be necessary. We probably don't need to optimize too much for it now. In fact, RECEIVE_BLOCKS could probably be removed altogether as part of #7119, if not for compatibility's sake. Once reusable blocks are refactored as an embedded editor, we'd probably remove all of this ignoring behavior, and treat it as a real change that should trigger change detection.

In the meantime though, this basically restores the behavior we had prior to #13088 rather faithfully (including all imperfections therein).

nerrad · 2019-04-11T12:30:34Z

packages/e2e-tests/specs/change-detection.test.js

+		// TODO: This should be considered a temporary test, existing only so
+		// long as the experimental reusable blocks fetching data flow exists.
+		//
+		// See: https://github.com/WordPress/gutenberg/issues/14766


Very good comment block explaining things 👍

youknowriad · 2019-04-11T14:44:40Z

packages/block-editor/src/store/reducer.js

+		const nextState = reducer( state, action );
+
+		if ( nextState !== state ) {
+			nextState.isIgnoredChange = IGNORED_ACTION_TYPES.has( action.type );


so what is exactly the difference between isIgnoredChange and ! isPersistentChange?

From __unstableIsLastBlockChangeIgnored docs:

An ignored change is one not to be committed by BlockEditorProvider, neither via onChange nor onInput.

From isLastBlockChangePersistent docs:

A persistent change is one committed by BlockEditorProvider via its onChange callback, in addition to onInput.

Effectively: Non-persistent changes are still surfaced up to the rendering Editor, but treated as omitted from history. Ignored changes are not surfaced to the rendering Editor at all.

Oh I think I got it, while one is about the onChange vs onInput the other is about not calling them entirely.
It does seems like they have the same roles though. Avoid undo levels, can't we unify and just use one?

(I replied to myself before I see your comment)

It does seems like they have the same roles though. Avoid undo levels, can't we unify and just use one?

This is a good summary of the problem. They're not the same. One is considered by withHistory, the other by withChangeDetection. The bug exists because we only accounted for the first, not the second.

If the question is whether "changes" should be a reflection of the presence of undo levels: I think long ago we had it this way, and it changed (presumably necessarily). Possibly as a result of some of the work to merge undo levels while still needing to consider them as changed.

👍 Thanks for the clarification, it makes sense.

If the question is whether "changes" should be a reflection of the presence of undo levels: I think long ago we had it this way, and it changed (presumably necessarily). Possibly as a result of some of the work to merge undo levels while still needing to consider them as changed.

I think the reason we don't consider Undo levels as part of post dirtiness is because Undo history doesn't reset when a Save occurs, but the post is "clean".

youknowriad

It fixes the issue in my testing. Hopefully we could find a solution for the embeded reusable blocks editor at some point and remove these hacks.

aduth · 2019-04-11T14:57:48Z

Thanks @youknowriad, @nerrad . Either Travis is being particularly stubborn today, or there may be a legitimate issue. I'll give it another reset.

youknowriad · 2019-04-11T15:00:32Z

This particular e2e test (deletion I think) with plugins enabled is unstable. Without plugins it's pretty stable though, so might be something to do with the plugins we're installing.

aduth · 2019-04-11T15:28:40Z

This particular e2e test (deletion I think) with plugins enabled is unstable. Without plugins it's pretty stable though, so might be something to do with the plugins we're installing.

Yeah, that deletion failure is quite nonsensical. The failure is that the content contains a reusable block, but the test itself is pretty straight-forward and involves no reusable blocks.

The other test with Undo, I could see some potential for race conditions prior to these changes, since the undo level could fluctuate depending on whether or not the reusable blocks fetch had time to complete. I would expect that should be improved here (fetch won't ever add the undo level).

…ress#14916) * Block Editor: Avoid creating new state reference on unchanging isPersistentChange * Block Editor: Consider received blocks state change as ignored * fixup a35fa82 * Block Editor: Regenerate documentation

* Block Editor: Avoid creating new state reference on unchanging isPersistentChange * Block Editor: Consider received blocks state change as ignored * fixup a35fa82 * Block Editor: Regenerate documentation

aduth added 3 commits April 10, 2019 15:47

Block Editor: Avoid creating new state reference on unchanging isPers…

c382c79

…istentChange

Block Editor: Consider received blocks state change as ignored

a35fa82

fixup a35fa82

1f9a41c

aduth added [Type] Bug An existing feature does not function as intended [Priority] High Used to indicate top priority items that need quick attention [Feature] History History, undo, redo, revisions, autosave. [Package] Block editor /packages/block-editor labels Apr 10, 2019

aduth requested review from youknowriad and ellatrix April 10, 2019 20:01

aduth requested review from ajitbohra, gziolo, nerrad, noisysocks, ntwb and talldan as code owners April 10, 2019 20:01

aduth added this to the 5.5 (Gutenberg) milestone Apr 10, 2019

This was referenced Apr 10, 2019

Block Editor: Reusable blocks fetching causes "Unsaved Changes" prompt #14910

Closed

Merely selecting a block after load creates undo level #14766

Closed

Block Editor: Regenerate documentation

4efa59b

aduth requested review from chrisvanpatten, mkaz, oandregal and notnownikki as code owners April 11, 2019 11:54

nerrad reviewed Apr 11, 2019

View reviewed changes

youknowriad reviewed Apr 11, 2019

View reviewed changes

youknowriad approved these changes Apr 11, 2019

View reviewed changes

nerrad approved these changes Apr 11, 2019

View reviewed changes

aduth merged commit 8722f49 into master Apr 11, 2019

aduth deleted the fix/14910-block-editor-receive-blocks-change branch April 11, 2019 15:40

This was referenced Apr 11, 2019

Editor: Trigger reusable blocks autocomplete when options generated #14915

Merged

Block Editor: Assign Provider isSyncingOutcomingValue only when blocks changing #14955

Merged

talldan mentioned this pull request Apr 15, 2019

Bump version number to 5.5.0-rc.1 #14981

Merged

aduth mentioned this pull request Apr 15, 2019

Plugin: Backport bug fixes from Gutenberg 5.5.0 to wp/trunk (WordPress 5.2 RC) #14987

Merged

jorgefilipecosta mentioned this pull request Apr 16, 2019

Fix: reducer tested properties not related to replaceInnerBlocks action while testing that action #15002

Closed

This was referenced Apr 17, 2019

Bump/5.5 #15011

Closed

Release/5.5 #15012

Closed

Bump plugin version to 5.5 #15013

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block Editor: Consider received blocks state change as ignored #14916

Block Editor: Consider received blocks state change as ignored #14916

aduth commented Apr 10, 2019

nerrad Apr 11, 2019

aduth Apr 11, 2019

nerrad Apr 11, 2019

nerrad Apr 11, 2019

aduth Apr 11, 2019

nerrad Apr 11, 2019

youknowriad Apr 11, 2019

aduth Apr 11, 2019

youknowriad Apr 11, 2019

youknowriad Apr 11, 2019

aduth Apr 11, 2019

youknowriad Apr 11, 2019

aduth Apr 11, 2019

youknowriad left a comment

aduth commented Apr 11, 2019

youknowriad commented Apr 11, 2019

aduth commented Apr 11, 2019

		@@ -775,6 +775,20 @@ via its `onChange` callback, in addition to `onInput`.

		Whether the most recent block change was persistent.

		### __unstableIsLastBlockChangeIgnored

Block Editor: Consider received blocks state change as ignored #14916

Block Editor: Consider received blocks state change as ignored #14916

Conversation

aduth commented Apr 10, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad left a comment

Choose a reason for hiding this comment

aduth commented Apr 11, 2019

youknowriad commented Apr 11, 2019

aduth commented Apr 11, 2019