Remove autosaveable check from autosave monitor

[ellatrix]

Description

This would be a quick fix for #10427. I'm not sure on the implications of removing the check in the autosave monitor. I'm also not sure if it would be a good idea to pass the selector function as a prop instead of the value, but like that we can call it only when needed. Again, unsure here if could get rid of this check and selector altogether... Would like some feedback around these issues from people who have worked on autosave before like @adamsilverstein and @aduth.

How has this been tested?

Ensure serialisation does not run on every keystroke after the initial autosave. This could be done by logging it.

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[aduth]

As I understand it, the issue may surface in that the endpoint returns error responses when a save is not needed. I've suggested before we handle this more gracefully, perhaps from the server, or ignoring the error response from the client.

[aduth]

We could potentially respect the current behavior by moving the isAutosaveable to be called once at the actual time of autosave in its effect handler.

[aduth]

I've been thinking more on this. A few ideas come to mind:

• Create a separate selector getBlockSaveContent which is memoized on block attributes, so that only the edited block is re-serialized.
  • This means the editor selector becomes aware of how to piece together block fragments which, while ultimately just a .join( '\n\n' ), still pierces the block abstraction.
• Move isEditedPostAutosaveable to be considered in the save effect handler after a post is marked as clean to avoid the network request if false, i.e. allowing AutosaveMonitor to call save on mere dirtiness, checking as valid autosave only once timer has elapsed.
  • This would probably require some shuffling in the effect handler to respect the REQUEST_POST_UPDATE_SUCCESS optimist success condition
• Remove isEditedPostAutosaveable, allow autosave to fire on dirtiness condition alone, handling the server error response as a no-op
  • This latter requirement might be a nice-to-have anyways in case somehow an invalid autosave request makes its way through.
  • There's some wastefulness here in that a change to a non-autosave-field would trigger an autosave request (e.g. category updates should ideally not trigger autosave because they're not accounted for)

The last of these seems like the most direct solution for the near-term, while allowing for future refactorings to improve upon its wastefulness.

There are additional options which surface if we'd have better insight into specific changed properties (#7409) since currently our dirty detection is rather "dumb".

[danielbachhuber]

I'll defer on the code review, as I don't have a strong understanding of the current abstraction.

[aduth]

@danielbachhuber FYI you were tagged for review since you were the sole approving reviewer / merger of #6257 wherein the issue was introduced.

[aduth]

Related alternative approach, which is a more involved refactoring: #10844

The viability of this one hasn't yet been determined.

[adamsilverstein]

We could potentially respect the current behavior by moving the isAutosaveable to be called once at the actual time of autosave in its effect handler.

That seems like a reasonable approach and should be the only time we really need to check this. Did you attempt that in this PR?

[gziolo]

This is confusing, why does it pass down selector rather than calling it here?

[aduth]

This is confusing, why does it pass down selector rather than calling it here?

From original comment:

I'm also not sure if it would be a good idea to pass the selector function as a prop instead of the value, but like that we can call it only when needed.

It is a bit strange, though I understand why it's being done. I think though that if we were to go this direction, I'd rather we move toward dropping all consideration of whether the post is autosaveable, and just use the "is dirty" with error tolerance from the autosave REST response for unneeded saves.

[gziolo]

Either way, we should document the solution to ensure that it doesn't get refactor by accident.

[youknowriad]

I'm going to move this out of 4.2 for now. but if you think it's ready please bring it back.

[aduth]

I don't think this is a viable approach due to how we re-"dirty" state after a save completes if there are remaining unsaved edits, as it has the very likely potential to become stuck in an infinitely repeating sequence of delayed autosaves. This occurs because we only pick content, excerpt, and title to send with the autosave, and anything else (e.g. categories) would be rightfully left as an unsaved edit. If all we're considering for the delayed autosave is a simple dirty check, it's going to get hit by this repeatedly.

gutenberg/packages/editor/src/store/effects/posts.js

Lines 179 to 186 in 9d46596

	// TEMPORARY: If edits remain after a save completes, the user must be
	// prompted about unsaved changes. This should be refactored as part of
	// the `isEditedPostDirty` selector instead.
	//
	// See: https://github.com/WordPress/gutenberg/issues/7409
	if ( Object.keys( getPostEdits( getState() ) ).length ) {
	dispatch( { type: 'DIRTY_ARTIFICIALLY' } );
	}

[aduth]

Superseded by #10844