-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PostPublishButton: Disable if saving non-post entities #33140
Conversation
Size Change: +13.9 kB (+1%) Total Size: 1.06 MB
ℹ️ View Unchanged
|
9f807ae
to
50e896f
Compare
* | ||
* @return {boolean} Whether non-post entities are being saved. | ||
*/ | ||
export const isSavingNonPostEntityChanges = createRegistrySelector( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that selector name is a bit confusing, it doesn't match what it's actually doing. Because in theory, you could be saving other posts (think query block) that are different from the main one being edited in the page.
So it's more like
isSavingExtraEntities
or isSavingMultipleEntities
or something like that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes me wonder though whether we should just check that we're saving any entity including the "post" one. I mean do we need the distinction in the component where we call the selector? Maybe the selector could be simpler if we just check whether there's an entity save in progress (regardless of which entity it is)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that selector name is a bit confusing, it doesn't match what it's actually doing. Because in theory, you could be saving other posts (think query block) that are different from the main one being edited in the page.
So it's more like
isSavingExtraEntities
orisSavingMultipleEntities
or something like that
That's true, but I modeled isSavingNonPostEntityChanges
pretty much after hasNonPostEntityChanges
, and the same points could be made about that selector, no? So I thought it'd make sense to name the "is-saving" counterpart to the "has...changes" selector similarly...
gutenberg/packages/editor/src/store/selectors.js
Lines 150 to 172 in 0216850
/** | |
* Returns true if there are unsaved edits for entities other than | |
* the editor's post, and false otherwise. | |
* | |
* @param {Object} state Global application state. | |
* | |
* @return {boolean} Whether there are edits or not. | |
*/ | |
export const hasNonPostEntityChanges = createRegistrySelector( | |
( select ) => ( state ) => { | |
const dirtyEntityRecords = select( | |
coreStore | |
).__experimentalGetDirtyEntityRecords(); | |
const { type, id } = getCurrentPost( state ); | |
return some( | |
dirtyEntityRecords, | |
( entityRecord ) => | |
entityRecord.kind !== 'postType' || | |
entityRecord.name !== type || | |
entityRecord.key !== id | |
); | |
} | |
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any thoughts about my second comment here, it makes the first one irrelevant because maybe the selector is not needed at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes me wonder though whether we should just check that we're saving any entity including the "post" one. I mean do we need the distinction in the component where we call the selector?
It seems like in the context of the PostPublishButton
, that would be fine (since it's all going into isButtonDisabled
and isToggleDisabled
anyway). About other contexts, I'm less sure. Even within the PostPublishPanel
, we have such props as isSaving
and isSaveable
(connected to the isSavingPost()
and isEditedPostSaveable()
selectors, respectively), but also forceIsSaving
😖 So that's not something I'm eager to touch 😬
Now if we're going to keep isSavingPost()
in a number of other contexts (at least for now), it does seem to make sense to me to have a selector that's complementary to it -- i.e. checks if we're saving changes to anything but the post that's currently being edited.
In the long run, it might make sense to replace isSavingPost()
by a wholesale isSavingEntities()
selector, but that'll require an audit of all callsites. For the time being, I think it would add to the confusion to use such a wholesale selector for "is-saving" detection, when OTOH we have a dedicated hasNonPostEntityChanges
for "is-dirty" detection.
Maybe the selector could be simpler if we just check whether there's an entity save in progress (regardless of which entity it is)
FWIW, that would basically just be __experimentalGetEntitiesBeingSaved()
, right? Which is the counterpart to __experimentalGetDirtyEntityRecords()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to me yeah. I have a feeling that our saving flow UI bits are way too complex and very hard to maintain for what they really are meant to do. they are also very old components that didn't see a lot of improvements over time aside the addition of adhoc multi-entities saving flow related changes but without rethinking the components themselves . I do think we need to check there for simplification/refactoring opportunities soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed! Coincidentally, here's a related UX issue: #33223
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good to me. Though I was wondering whether a simplification is possible #33140 (comment)
We're currently not disabling the Publish/Save/Update button while saving non-post entity changes (such as changes made to a reusable block, or to general site settings through a special block such as the Site Title block). To fix this, this commit introduces a selector called `isSavingNonPostEntityChanges`, and a few helpers.
Description
Second stab at #32889; needed for #32868.
We're currently not disabling the Publish/Save/Update button while saving non-post entity changes (such as changes made to a reusable block, or to general site settings through a special block such as the Site Title block).
To fix this, this PR introduces a selector called
isSavingNonPostEntityChanges
, and a few helpers.How has this been tested?
trunk
, they will be enabled; on this PR, they will be disabled.trunk
, try clicking 'Cancel' while the spinner is still there. Reload the page (and discard any changes), and observe that the site title hasn't been changed.Screenshots
Before:
After: