-
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
Update/edit flow for blocks which have a media placeholder #14918
Conversation
This is looking great so far, @draganescu! I took it for a quick spin, and noticed just a couple small bugs:
|
@kjellr so far there are three problems I know of:
Also I have marked this WIP b/c some of the code could be made more DRY and the edit/view pattern could be made the same in all blocks, maybe have an edit/view wrapper component? |
467993b
to
74c28dd
Compare
df469d8
to
8080368
Compare
Rebased and updated with new snapshot so tests will pass. I think it's ready for review. Aside from code DRY-ness, there might be a point where we could make the code in these blocks more "standard" but maybe we could move ahead like this for now and refactor in a separate PR. @kjellr if you can take it for another spin that'd be great! :) |
Thanks, @draganescu! This is looking great. I noticed just one small bug: For embed blocks, the "Cancel" link appears even before you enter a URL: Once that's all set, I think this is all set from a design perspective. Before we decide to move ahead for sure though, I'd love to get @jasmussen's thoughts on the DRY issue. He may have an idea for a quick fix. |
This is nice work, and it solves a problem, which is great. Like Kjell, I think it's close to shipping as an enhancement to what we have. There's just one issue that needs to be fixed before that: In this screenshot the edit image button appears to be part of the alignment group. The edit image button should always be its own group, and never be part of any other groups, because its behavior is different. All this said, I feel like this interface also starts to show some of the limitations of the current placeholder interface we have, and suggests that we should separately look at improving this in a holistic way.
I don't feel like those issues are blockers for shipping this improvement. But it does feel like there is an opportunity to step back for a second and think: if we tackled appenders, edit buttons, and placeholder/setup states together, what could that do to improve the user experience? What could we eliminate? What could we improve? |
8080368
to
72d6ba2
Compare
rebased, fixed the button'd group (thanks @jasmussen), removed the cancel link (thanks @kjellr). @afercia if you could take it for a spin to make sure I didn't introduce accessibility issues with this update, that'd be awesome, thank you! |
36a6379
to
dfbc4cd
Compare
4b4b9a8
to
131fbcc
Compare
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've made my way through about half the code, but there's quite a lot. I defo feel this could be split up into a PR per block. It'd be much easier to refine and ship each one indivdually.
One thing that having all the changes in one PR makes clear is how different yet the same all the media based blocks are. It'd be great to see some steps towards making the code the same across each one, even if it's just using the same style of code (methods vs inline functions, naming conventions).
Then it'd be easier at a later point to try to refactor them all to use some common code.
@@ -103,7 +107,7 @@ class AudioEdit extends Component { | |||
const { setAttributes, isSelected, className, noticeOperations, noticeUI } = this.props; | |||
const { editing } = this.state; | |||
const switchToEditing = () => { |
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.
The function should probably be renamed to something like toggleEditing
.
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 also noticed this function doesn't speak
when switching while some of the other blocks do.
<BlockControls> | ||
{ !! src && ( <Toolbar> | ||
<IconButton | ||
className={ classnames( 'components-icon-button components-toolbar__control', { 'is-active': this.state.editing } ) } |
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.
No need to add the components-icon-button classname, this is added by the IconButton component itself.
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.
Also, it seems like is-active
would always be true as this is within an if statement if ( editing ) {
@@ -143,7 +160,7 @@ class AudioEdit extends Component { | |||
className="components-icon-button components-toolbar__control" |
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.
Same issue with the components-icon-button
classname. Looks like it was an existing issue.
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.
Seems a shame to have to duplicate the code for this IconButton. Maybe it can be extracted to a separate component in the same file? Or the rendering logic could be reworked.
onDoubleClick={ this.toggleIsEditing } | ||
onCancel={ !! url && this.toggleIsEditing } | ||
notices={ noticeUI } | ||
onError={ this.onUploadError } |
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.
Is this right? I couldn't see an onUploadError method.
<BlockControls> | ||
<Toolbar> | ||
{ !! href && ( <IconButton | ||
className={ classnames( 'components-icon-button components-toolbar__control', { 'is-active': this.state.isEditing } ) } |
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.
components-icon-button
again
|
||
if ( ! href || hasError ) { | ||
if ( ! href || isEditing || hasError ) { |
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.
Might be able to drop ! href
here, since isEditing
is now initialised to the right value.
Thanks @talldan! It feels like a great moment to refactor some code indeed, my fear is that other PRs on these blocks plus refactoring will make some mega conflicts given time :D. I will try to split in more than one PR and see how that goes. Not sure about the issues when logged in as a contributor and how the media placeholder could have caused them :/ |
131fbcc
to
2b129f3
Compare
@draganescu - we can try to push this through for all the blocks, but based on experience I've seen that smaller PRs tend to ship more quickly and are more likely to be reviewed. They're also much easier to test. Focussing on one block at a time is what I'd personally try to do. A good way to do it might be to checkout the files from this branch for one block onto a separate branch. Haven't tried it but something like this might work to bring the changes across onto a new branch:
|
@talldan as suggested I've split this into multiple PRs for easier review. I have also incorporated the bits collected from your past reviews (hopefully) in the new PRs. Here they are: Audio BlockCover BlockEmbed blockMedia + Text BlockVideo blockFile block |
Description
Closes #14795
This is a follow up to the image block edit flow update which ports the new flow to all the blocks which have media with an edit state. The blocks affected are:
How has this been tested?
For now I've only tested locally.
Types of change
New feature (non-breaking change which adds functionality)
Screenshots
Media + text
Cover
Audio
File
Video
Embed