Editor: Refactor AutosaveMonitor to a function component

[Mamaduka]

What?

Part of #22890.
Supersedes #78630. This is a full refactoring, instead of a 1-to-1 mapping of Class to Function component, which AIs often do.

PR refactors AutosaveMonitor into a function component with data hooks. Here's what's changed:

• Converts AutosaveMonitor from a class + compose/withSelect/withDispatch HoC to a function component using hooks.
• Reads editor state with on-demand useSelect( store ) getters inside the timer tick instead of subscribing to it.
• Narrows the public API to interval and autosave; the rest (isDirty, isAutosaveable, editsReference, isAutosaving) are now internal.
• Removes the disableIntervalChecks prop.
• Collapses the timer logic into a small useInterval helper and a single ref.

Why?

• The HoC subscribed to editsReference, which changes on every edit — so the component re-rendered on essentially every keystroke. Reading the state on demand at each check removes those re-renders.
• disableIntervalChecks was only ever used by the native mobile layout, removed with the rest of React Native (Remove React Native implementation, framework, and dependencies #78747); this was dead code.
• The injected isDirty/isAutosaveable/etc. Props were implementation details of the old HoC, not the real API.

Testing Instructions

1. CI checks should be green.
2. Smoke tests autosaving feature.

Testing Instructions for Keyboard

Same.

Use of AI Tools

Assisted by Claude.

[Mamaduka]

This could be useEffectEvent in the future.

[jsnajdr]

It could immediately be useEvent from wp-compose, we already have this helper available, it assigns the callback to an internal ref and returns a stable wrapped callback.

[Mamaduka]

ESLint will still think that the callback needs to be declared as a dependency, not a deal breaker, but it can get annoying really fast if we start using our version of the hook.

[jsnajdr]

I see, useEffectEvent return values are treated as a special exception by the exhaustive-deps rule, they don't need to be in the dependency array. I didn't know that before.

Still, it's not a big deal, we already have to declare essentially constant things like useCallback or useDispatch return values.

We'll have to wait for a potentially long time until we can use React 19-only APIs, so using useEvent in the meantime is a good idea.

It's totally not a blocker for this PR, it's more like discussing the best practice for mid-term future.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: -188 B (0%)

Total Size: 7.5 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	475 kB	-188 B (-0.04%)

_{compressed-size-action}

[tyxla]

Thanks @Mamaduka, this looks like a reasonable refactor. There are a few little areas where we're not exactly compatible with the previous behavior, see comments.

[tyxla]

If isEditedPostAutosaveable() is false because the existing autosave is still loading, a pending edit can wait another full interval after autosaveability returns. The previous behavior always retried after 1 second.

[Mamaduka]

Sorry, should've mentioned this in the description. It was an intentional call on my end, but I will check the git history if that's a behavior we should keep.

[tyxla]

Correct me if I'm wrong, but I believe the old code did setAutosaveTimer( 1000 ) when ! isAutosaveable, retrying every second. The new code just returns and waits for the next setInterval tick, up to interval seconds, which could be up to a minute. I'm not 100% convinced this is the desired behavior.

[Mamaduka]

Claude and I did a little digging into the history. The 1s retry came from #23962 (the fixed-schedule rewrite back in 2020). As far as I can tell, it was just an incidental detail of that refactor. And isEditedPostAutosaveable() is only false in transient states (autosaves still loading on mount, or a temporary autosave lock), so in practice the only cost is a one-interval delay in a brief post-load window.

I also checked legacy core autosave.js - there's no 1s fast-retry there at all. It blocks for 10s when a save is in flight and otherwise runs on the heartbeat interval (~60s). So dropping the retry actually moves us closer to the core's behavior, not further.

Given that, I'd lean toward keeping the simpler fixed schedule. Reintroducing the retry means bringing back a variable timer, which is exactly what this refactor cleaned up.

[tyxla]

Hmm, I'm not sure it was an incidental detail / unintended. The PR description includes this as part of the intended mechanism:

If the handler is running at a time when isAutosaveable is false, keep retrying every 1 second.

To me, that looks quite intentional. I wonder if @adamziel or @youknowriad will recall. It's been 6 years 😬

[Mamaduka]

IMO, I would prefer the behavior to be similar to core. Since it hasn't been changed in years, it's safe to assume it's working and that consumers don't care about special behavior.

[tyxla]

There's no easy way to find out if folks were really relying on this behavior without trying out. So I'm good to try, and being consistent with what's been there forever makes sense. Let's keep an eye out for reports.

[jsnajdr]

The autosave logic is rather chaotic and after staring at it for 40 minutes I still don't get it ☹️

The isEditedPostAutosaveable checks if the post is eligible for autosaving:

1. It can't be completely empty, must have title or content or excerpt
2. Its post type must support autosaving in the first place
3. Saving must not be locked
4. It must be sufficiently different from the last autosave

Then the useInterval callback does its own check:

1. There has been some editEntityRecord, undo or redo since last check
2. The post is dirty. I.e., different from last save (not last autosave!). How is "being dirty" different from "having a recent edit" from the previous condition? I don't know.
3. The autosave is not already in progress.

The old version switched between 1s interval and 60s interval depending on isEditedPostAutosaveable. That makes sense for some parts of the condition: autosaving got just unlocked, autosaves finished fetching from REST. But what about the actual user-initiated changes? Why some of them wait for 60s and some only for 1s?

To make it even more convoluted, the <AutosaveMonitor> component is used also in <LocalAutosaveMonitor> with a custom interval (15s) and autosave callback (saves to local storage). Even though the local monitor saves to local storage, it still compares against the last server-side autosave, and cares about isAutosaving, i.e., whether server-side autosave is in progress.

I think we'll have to reformulate the requirements for autosave behavior, basically from scratch, to make any sense out of this.

[Mamaduka]

I agree that the logic is chaotic and all over the place, but the goal of this PR is to refactor away from the legacy class component and HoCs while preserving old behavior as much as possible.

That's also one of the reasons I didn't handle notice colocation here.

I think that a full logic rewrite is better done in a follow-up.

• Audit what makes a post eligible for autosave. Conditions should be almost the same for both local and remote autosaves.
• Colocate components and reuse parts instead of full components.
• Once LocalAutosaveMonitor doesn't depend on AutosaveMonitor, move notice handling there.

[jsnajdr]

OK, the only major difference I see now between the old and new version is that the old version has a much faster heartbeat (1s) while isEditedPostAutosaveable is false. We might want to revisit that in a followup. It's hard to tell how important this is, with the overall logic being so chaotic.

[jsnajdr]

One related refactoring that would be nice: the autosave warning notice is displayed by the EditorProvider component:

https://github.com/WordPress/gutenberg/blob/trunk/packages/editor/src/components/provider/index.js#L349

while the similar notice for local (local storage) autosaves is displayed by LocalAutosaveMonitor.

It would be nice if the remote autosave notice was moved to AutosaveMonitor. Then all autosave concerns would be covered by this one component.

Doesn't need to be a part of this PR, but it's something I noticed while trying to fix the flaky test in #78706.

[Mamaduka]

Good point, @jsnajdr!

I'll address @tyxla's feedback and then will colocate the notices.

Update

@jsnajdr, decided to handle that separately, it involved more chores, and it's better to keep changes atomic.

[tyxla]

@Mamaduka, this is looking good to me! The only remaining concern I have is this one.

[tyxla]

This one is good to ship from my perspective now.

@jsnajdr did you have any other suggestions before we ✅ and 🚢 ?

[jsnajdr]

did you have any other suggestions before we ✅ and 🚢 ?

My main concern is that I have hard time understanding the autosave logic.

[jsnajdr]

Let's move forward with this

[Mamaduka]

Thanks for the reviews, folks! I'm going to merge this and create an issue for follow-up(s).