Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
PostPublishButton: Disable if saving non-post entities #33140
Changes from all commits
a085c04
c979ca3
8245031
50e896f
dc72ccb
ff1ca28
73c59c2
61d0634
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 thatThere 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.
That's true, but I modeled
isSavingNonPostEntityChanges
pretty much afterhasNonPostEntityChanges
, 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
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.
It seems like in the context of the
PostPublishButton
, that would be fine (since it's all going intoisButtonDisabled
andisToggleDisabled
anyway). About other contexts, I'm less sure. Even within thePostPublishPanel
, we have such props asisSaving
andisSaveable
(connected to theisSavingPost()
andisEditedPostSaveable()
selectors, respectively), but alsoforceIsSaving
😖 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 wholesaleisSavingEntities()
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 dedicatedhasNonPostEntityChanges
for "is-dirty" detection.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