-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add 'Reset' option to MediaReplaceFlow component #64826
Conversation
…ured-image blocks
Size Change: -354 B (-0.02%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
…enhancement/MediaReplaceFlow-reset-option
…enhancement/MediaReplaceFlow-reset-option
Flaky tests detected in 0c3716a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10590857495
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Nice, this feels like a good cleanup and optimization. I think this just needs a code review. Great PR! |
mediaUrl={ | ||
useFeaturedImage && featuredImageURL | ||
? featuredImageURL | ||
: mediaUrl | ||
} |
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 looks unrelated. Can you explain why we're removing special handling for featured images?
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 condition is already handled here when passing argument to ToolbarEditButton
. Don't see any need to add same condition again in ToolbarEditButton
component.
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 sense!
closeAndFocus(); | ||
onResetImage(); |
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.
Besides this component and the Cover block, all reset callbacks are the same as onSelect( undefined )
. I wonder if we really need a new onReset
callback.
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.
We can make it optional by setting onSelect( undefined )
as default action for Reset
option.
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 adds more logic that MediaReplaceFlow
needs to handle, and I was thinking the opposite; it already supports too many "on-action" callback props.
@ramonjd, @andrewserong, what do you think?
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'm torn.
A benefit is that consumers don't have to include their own <MenuItem />
and onClose()
functionality. I see that, in trunk, the menu hangs after reset
The downside is that the "Remove" item won't be customizable for each block or file type. What if, later, the copy needs to update, e.g., Remove [specific item]
or extra accessibility props — then we'd be loading <MediaReplaceFlow />
again. For that reason this optimization could be premature.
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.
and onClose() functionality
Child functions get passed that any way I see:
? children( { onClose } ) |
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.
After adding "Reset" support to most media blocks in the core, I see this as more consolidation than optimization.
I'm pro-composition, but here, it seems we want to have the same feature/label across the blocks.
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.
Good discussion! I suppose one potential challenge with removing the onRemove
prop and consolidating around it calling onSelect( undefined )
is that the MediaReplaceFlow
component appears to be a public / stable one. Would consumers be guaranteed to handle it, i.e. what if someone has a callback that always expects a value? And should consumers always have a Reset option?
I suppose one of the neat things about the onRemove
prop is that if consumers don't provide a callback, the option will never be displayed, so it's backwards compatible in case anyone has code that wouldn't handle onSelect( undefined )
gracefully.
But I don't feel too strongly either way on this topic 🙂
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.
Thanks, good point, @andrewserong!
If consumers don't expect the "Reset" button, the block editor shouldn't surprise them with one :)
Having a new onReset
prop and conditional rendering will allow us that.
Thank you @Mamaduka, @ramonjd and @andrewserong. I'll Merge this PR now. |
* Add reset option in MediaReplaceFlow component * Add media reset option in toolbar of media-text block * Refactor MediaReplaceFlow component use in cover, image and post-featured-image blocks * Refactor MediaReplaceFlow component use in site-logo block * Refactor BackgroundImageControls component under global styles * Add media reset option in video, audio and file blocks * Fix onReset argument value error on image block * Remove unused MenuItem component from blocks * Reset attribute on reset option click in file block * Fix issue of reset option in media-text block Co-authored-by: akasunil <sunil25393@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org>
What? and Why?
Reset
option is used to clear media from block, such as image block, cover block etc. However, theMediaReplaceFlow
component does not by default have theReset
option available. We used to add theReset
option as a child of theMediaReplaceFlow
component, Whenever necessary. We had to include theReset
option in theMediaReplaceFlow
component itself because it is a fundamental feature that is needed anywhere media is used, saving us from having to write additional code.How?
This PR,
Reset
option toMediaReplaceFlow
Component.MediaReplaceFlow
component inImage
,Cover
,Post Featured Image
,Site Logo
blocksReset
option toAudio
,Video
,File
andMedia-Text
block.MediaReplaceFlow
component in background support under global styles.Testing Instructions
Image
,Cover
,Post Featured Image
,Site Logo
,Audio
,Video
,File
,Media-Text
)Reset
option is visible in toolbarReset
Testing Instructions for Keyboard
Screenshots or screencast