Status badge and "Review changes" only update after ~10 seconds

There: I propose to simply make mutations to the layout (POST or PATCH to /xb/api/layout/…) to change:

An alternate proposal

In preview.ts in previewApi.endpoints.postPreview.onQueryStarted trigger a clientside invalidation and force pendingChangesApi.endpoints.getAllPendingChanges to invalidate.

It would require adding a cache tag to getAllPendingChanges and using something like https://git.drupalcode.org/project/experience_builder/-/merge_requests/7... from onQueryStarted

#4: that works too, but does require an extra request. I know that the polling is still ongoing, and so this would just change the polling rhythm, if you will.

But … #4 is inevitably more concurrent requests immediately after making changes. And hence also more Drupal bootstraps.

I think in my proposal, we can even reduce the polling frequency, to say, every 30 seconds. It'll still feel instantaneous.

Yes but it does require making use of RTK Query internals - https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates which as @balintbrews has pointed out

We recommend using automated re-fetching as a preference over manual cache updates in most situations.

Just to be clear, I'm not against manual cache updates, PreviewEnvelope was designed for this purpose

So you're saying: your MR fixes it with a +13,0 diffstat, barely more than my OpenAPI-only change 🤣

Yeah, that's a no-brainer! Can't wait to test that tomorrow! 😄 (Would be happy to insta-merge after manual testing, and to move what I proposed to a new issue for a distant future.)

Will test @larowlan's MR after lunch 👍

Well … that totally works 😄🤩

wim leers → closed merge request !722

I may have found a regression so am looking into it. Clicking publish all changes shows the happy green smiley but then flashes back to show "Publish all changes" again

hooroomoo → credited jessebaker → .

Adding credit for @jessebaker for pointing me to the manualRetch that might not be necessary anymore and removing it fixed the regression i was looking at

@hooroomoo I've manually tested this and can't find any issues.. I can reproduce the delay on 0.x but with the MR in place it's gone, the Published > Changed label updates almost instantly.

I reverted @hooroomoo's changes after we tested in a zoom call and found the behaviour reported in #13 actually exists in HEAD too - 🐛 Auto save shows a change when there is not one Active

I've implemented the change of dispatch ordering per my review and that

a) fixes the bug from this issue
b) keeps things the same as they are in head for 🐛 Auto save shows a change when there is not one Active (i.e. it takes 10s for it to (wrongly) report 1 change - which is what was happening in #13 but immediately rather than after 10s

I think this is ready to go

Automatically closed - issue fixed for 2 weeks with no activity.