Only save metaboxes when it's not an autosave

[danielbachhuber]

Description

Improves autosave behavior to disable accidental saving of metaboxes. Metaboxes should only be saved on full saves.

See conversation in https://wordpress.slack.com/archives/C02QB2JS7/p1529698040000346

Fixes #7135

How has this been tested?

1. Open a new post in Gutenberg. Make sure your editor includes a metabox.
2. Type some text and wait for an autosave.
3. Type additional text and wait for a second autosave.
4. Hit "Save Draft" a first time.
5. Hit "Save Draft" a second time.

When the revision UI appears in Post Settings after step 5, it should indicate 2 revisions, not 4:

Previously, the two autosave events would trigger full save events / revision creation.

Screenshots

Types of changes

Bug fix.

Checklist:

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

[jasmussen]

Thanks for working on this.

Interesting question pops up for me — if we were to want to look at an autosave overhaul in a distant future version of Gutenberg, one where there is no button at all, there's just an autosave that kicks in when a change is detected, we probably wouldn't be able to make that work for metaboxes. In such a future, could we make the button appear explicitly only when metaboxes are present?

[youknowriad]

I think it's not correct at 100% to use the onChangeListener to call the listener while also watching for changes in the isAutosavingPost selector. Maybe we could add support for watching multiple selectors in onChangeListener or just drop it and use custom logic.

[danielbachhuber]

Maybe we could add support for watching multiple selectors in onChangeListener or just drop it and use custom logic.

What custom logic would you use?

[youknowriad]

Just checking both selector results without extracting the logic in a utility like onChangeListener

let wasSavingPost = select( 'core/editor' ).isSavingPost();
let wasAutosavingPost = select( 'core/editor' ). isAutosavingPost();
subscribe( () => {
  const isSavingPost = select( 'core/editor' ).isSavingPost();
  const isAutosavingPost = select( 'core/editor' ).isSavingPost();

  const shouldTriggerMetaboxesSave = wasSavingPost && ! wasAutosavingPost && ! isSavingPost && !isAutosavingPost; // not certain about this check entirely

  // Restore 
  wasSavingPost = isSavingPost;
  wasAutosavingPost = isAutosavingPost;

  // trigger
  if ( shouldTriggerMetaboxesSave ) {
    // do something.
  }
} ) 

[danielbachhuber]

Do you think this custom logic is better than what I have? At first glance, what I have already seems more precise.

[youknowriad]

It's not about better or worse, it's about the fact that we want to run the listener whenever the value of isAutosavingPost's selector changes. In your code it's not the case, if for some reason (even if it's not possible at the moment) isSavingPost doesn't change but isAutosavingPost does, your listener is not being executed and I don't think it's intentional.

[danielbachhuber]

subscribe( () => { fires for every change, which seems too frequent. Is there an alternative you'd suggest?

[youknowriad]

There is none actually, we can bundle the multiple selectors support into onChangeListener. Maybe by supporting an "array of selectors" instead of a given "selector" as an argument passed to onChangeListener but in terms of performance, it doesn't change anything compared to my logic above.

That's how redux work in general, a unique eventEmitter calling all its listeners, It has proved to scale well in several contexts.

[danielbachhuber]

Ok, updated in ed79968

[youknowriad]

LGTM 👍 Thanks for the updates

[aduth]

Some previous context / discussion at #6257 (comment)

Open questions:

• What's the relationship between autosave and saving meta box values? This has not been changed from its previous logic, where metabox updates trigger in response to the start of a save request (including autosave).

[danielbachhuber]

@aduth Does your comment block merge?

[aduth]

Nope.