Media flow component for media replace

[draganescu]

Description

Refactored following the suggestion from @youknowriad to no use DropDownMenu at all. Re implementing using a simple PopOver.

Closes #11952

Outstanding issues

• Refactor so that no changes are applied to DropDownMenu
• [ ] Accessibility issues described by @enriquesanchez here
• The "Insert from URL" needs an aria-expanded attribute to communicate when the form is expanded/collapsed
• When inserting / replacing media, the result of the action should be announced with a speak() message

This component should be dropped in any media block 's toolbar and add the media edit functionality.

This component, in order to work, had a few hurdles to handle:

1. The is a z-index conflict that makes the suggestions from an url input appear below the popover when the popover is in a toolbar. The issue appears when the popover is displayed at the bottom and the problem is in _z-index.scss line 95, not sure what problem it solves there.

2. The ObserveTyping component needed || target.closest( '.components-popover' ) to determine the typing is in the toolbar. There was a condition but now that we have a popover in the toolbar I found no other solution than to look for the popover container. Not sure this is the best way though.

3. The LinkEditor component has some props forwarded to the URLInput it handles so we are able to show it with a border and full width.

4. The DropdownMenu component needed two new props:

• a showLabel prop that determines to show the label instead of the icon, when there is no icon
• an onToggleHandler prop which is a function that is called by Dropdown on toggle. This was the only solid way to have the URLInput hidden when the menu was closed and opened again.
• some style was added to have the arrow correctly spaced from the label as well

5. The Toolbar component passes down showLabel and ... otherProps to DropdownMenu so we can set these in MediaFlow.

[jorgefilipecosta]

I like the idea of abstracting this flow, and it would make the life of block developers easier. Getting the shape of the right abstraction is a hard task; in our blocks, we have subtle differences in the flows. Let us try to use the MediaFlow component in all the media blocks, so we understand what can be abstracted and what cannot. Our blocks are a good sample of the needs block developers may have.

[draganescu]

I have changed this to fit closer UX wise to how it is described in #11952 but am still working on collecting an image URL from the replace image drop down.

The one thing where some technical feedback would be nice is this:

• the dropdown menu closes itself when one clicks or focuses outside
• the media upload component renders a specific thing: the button to open it. The url input does the same and allows for autofocus.
• therefore the moment you mount/open something from the dropdown menu it unmounts and tears down the things you mounted from it.

Case in point, opening the media modal from a menu item will trigger the removal of the modal's contents (@gziolo you might know something about this and why it's needed).

To provent this, the dropdown should be allowed to stay open but on the other hand that means it may only be closed by clicking on the toggle handle again, not very nice.

What other ways are there?

[draganescu]

@mapk this is how it looks to use it so far, clicking the media library and the upload menu item do the job, I am still working on the URL inserter:

[talldan]

therefore the moment you mount/open something from the dropdown menu it unmounts and tears down the things you mounted from it.

Other modals are usually implemented like this:

{ isModalOpen && ( <Modal ... /> ) }

but this one is different because it's not a react modal and the component also has a render prop for the opening button. The only option I see with the current code is to render the Toolbar in the render prop for MediaUpload.

As an alternative that requires a bit of a refactor, the code for the modal could be extracted to work more like a normal modal. @jorgefilipecosta any thoughts on whether that would work?

[mapk]

It's looking amazing, @draganescu! I can't wait to see how the "Insert from URL" ends up.

One thing I noticed is the dropdown arrow and the word "Replace" needs more spacing to match the other icons that use a dropdown arrow. Here's an example of how it is in this PR:

[youknowriad]

This is looking like a great start but I'm personally not convinced yet that we need a MediaFlow component. My concern is that for the sake of factorization, we'll add a lot of checks (if/else), props where it would have been ways simpler to just compose the inner components (MediaPlaceholder, MediaReplaceControl) in the block itself.

Maybe we can start by just adding a MediaReplaceControl to a specific block and then start thinking about genericity as we move towards implementing it in other blocks.

[mtias]

Maybe we can start by just adding a MediaReplaceControl to a specific block and then start thinking about genericity as we move towards implementing it in other blocks.

I agree, I'd like to also see this flow in practice before an abstraction is in place and we extend it to every other block.

[draganescu]

Ok @mtias @youknowriad I will switch this to a MediaReplaceControl and implement that in the image block in a separate PR.

We have had the media flow component idea because of the fact that adding the current image editing flow to all the other media blocks proved a difficult and entangled process and we found that there was a lot of duplication between the media components.

On the other hand, the new UX is completely different so maybe having a MediaReplaceControl proves to be easier to distribute to all media blocks.

[draganescu]

@mtias and @mapk take this for a spin and let me know how it feels. Currently all the actions work with the audio block on this PR. It is not exhaustively tested, just looking to know if the interaction is what you have in mind.

[mapk]

Just ran through another design review. I like how this is turning out! Here's some notes.

1. The "Apply" button hover state needs to match the Image block.

2. When not focused, the input field is missing a border.

3. Clicking away from the popover should cause the URL input field to collapse again.
4. The "Search" popover appears below the other popover. It should appear on top.

[jorgefilipecosta]

I left two simple change suggestions but I think the PR is good to go from the code point after the suggestions are applied.

[talldan]

Thanks so much for taking all those comments into account. I only have one comment on the code and it's a really tiny thing and not blocking.

outdated

[talldan]

I gave this a test and I'm still seeing an issue when inserting from url. I tried it out using the google logo as the url:
https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png

The menu seems to end up scrolled to the right:

It seems to be related to the length of the URL. In debugging, removing white-space: nowrap; from the .block-editor-url-popover__link-viewer-url class styles seemed to solve it. If that gets removed, the various url inputs will need some testing across browsers to make sure everything still looks good.

[talldan]

@draganescu 6994c1d seems to include a bit more than just css changes (selectURL and onClose have changed). Would you be able describe why those changes were needed?

[draganescu]

@talldan aside from the CSS that keeps the link viewer short in Chrome, I noticed that the behaviour of the URL input was broken as in: when you close and open the pop over the Insert From URL option should revert to the default state, which is closed. So I added those lines to reset its state on pop over close and when an URL is selected.

[talldan]

@draganescu I'm not sure about that. It doesn't collapse when you click away from the popover normally, so I don't see why it should collapse when a url is submitted. I also feel like leaving it visible is an indication that the source of the media was inserted from a url. Alternatively, perhaps it should always be visible when an external url is used, but collapse automatically when an internal one is used.

Anyhow, this is a debatable point. I think the PR is in good shape so we should merge it, and then ask for some design input on this specific user flow.

outdated

[draganescu]

Yea @talldan I thought about it some more, plus fiddled with the component and I think you are right that keeping the link viewer open is a kind of an indicator that the URL is the source of the image, especially since it is optional to change it. So I added a commit that removes that auto collapse behaviour.

I like your suggestion about always open the viewer on external URLs! Will open an issue to propose that, but would love to have this merged and collect some real world feedback as well.

[scruffian]

I made a small suggestion to improve this here: #19063