Skip to content
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

ImageSizeControls: Replace ButtonGroup with ToggleGroupControl #65386

Merged
merged 15 commits into from
Oct 29, 2024

Conversation

hbhalodia
Copy link
Contributor

What?

PR replaces the ButtonGroup component with ToggleGroupControl in the ImageSizeControls.

Why?

Testing Instructions

  1. Open any post or page.
  2. Add latest post block.
  3. Enable option to display featured image.
  4. Check for the image size controls.
  5. Should work as expected as before.

Testing Instructions for Keyboard

  • Same

Screenshots or screencast

Before After
Screenshot 2024-09-17 at 11 02 49 AM Screenshot 2024-09-17 at 11 01 44 AM

@hbhalodia hbhalodia requested a review from ellatrix as a code owner September 17, 2024 05:33
Copy link

github-actions bot commented Sep 17, 2024

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: hbhalodia <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: kevin940726 <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@mirka mirka requested a review from a team September 18, 2024 14:00
@mirka mirka added [Type] Enhancement A suggestion for improvement. [Package] Block editor /packages/block-editor labels Sep 18, 2024
@ciampo ciampo changed the title Fix: Replace ButtonGroup usage with ToggleGroupControl - Issue 65339 ImageSizeControls: Replace ButtonGroup with ToggleGroupControl Sep 18, 2024
}
value={ addSelectedScaleValue() }
isBlock
isDeselectable
Copy link
Contributor

@ciampo ciampo Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed here, isDeselectable doesn't really work with text options — we should remove it.

One option could be to add an "Auto" option which replaces the 'reset' button. What do you think, @mirka @t-hamano ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we remove the isDeselectable prop, keyboard users won't be able to set a custom value:

71dcd41756d30d74f869d014456c5284.mp4

As I commented here too, we might need to add an option called "Custom".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keyboard users won't be able to set a custom value

This isn't inherently true — it's only because the logic of addSelectedScaleValue doesn't account for it. In fact the current logic sets invalid values on the ToggleGroupControl, when it should be set back to undefined instead. (cc @hbhalodia)

For the sake of this PR, I'm ok with just replicating the existing functionality. And as it turns out, the Reset button doesn't actually reset, it just sets it to 100%, which is different from an actual reset. So to actually reset, the user needs to clear the width/height input fields. I think that means we don't even need a Reset button nor a "Custom" option to replicate the existing functionality.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mirka, If I had read it correct, need to update the logic on addSelectedScaleValue() function should return undefined, when we set custom values? is that something need to changed.

Thank You,

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's only because the logic of addSelectedScaleValue doesn't account for it. In fact the current logic sets invalid values on the ToggleGroupControl, when it should be set back to undefined instead.

Hi @mirka, I tried to set directly undefined on that logic, seems like anyhow keyboard user would ultimately land on the first option of the ToggleGroupControl, which ultimately sets the first option even we have undefined set on that logic.

Can you please let me know how to set it undefined for keyboard users on that logic, because ultimately when user lands on the toggleGroupControl it would call handleUpdateDimension() which ultimately sets the dimension based on the scale size, and it would remove the custom dimension set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mirka @t-hamano, This is now looking good. Below is the demo screencast. I guess we can go ahead with the PR, let me know if I need to address any other feedbacks.

GBissue-65339.mov

Thank You,

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may have lost the plot a little bit, but I noticed that unit tests are failing because they require a "reset" button. With the changes from this PR, would a user be able to reset the value at all? Is that something that we should retain?

Again, apologies in case I missed the part of the conversation where we reached an agreement on that aspect.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would a user be able to reset the value at all? Is that something that we should retain?

The reset button in the original was the functional equivalent of re-selecting the "100%" option. The user can also still delete the values from the number inputs. So, I'd say no functionality is lost.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the changes from this PR, would a user be able to reset the value at all? Is that something that we should retain?

In the current specification, when we press the reset button, the width/height values ​​are set and 100% is selected. These values ​​are not saved in the database. In addition, when we reload the browser, the width/height values ​​and the 100% selection are cleared.

This lack of consistency bothers me, but at least the reset action is considered to be the same as 100%, so I think a reset button is not necessary.

4ba662ea53e68b1a6cfa11351a23a5db.mp4

The presence or absence of a reset button has been discussed in other PRs, and there may not be a complete consensus yet, but my understanding is as follows:

  • Search Block (#65340): If we want to reset the value, we need to empty the custom value input field.
  • Button Block (#65346): Since there is no custom input field, there needs to be some way to make the value empty (auto). One approach being considered is adding an "Auto" option.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, Lena and Aki — much more clear now. We established that no functionality is lost.

The lack of consistency is also bothering me. I say we merge this PR with the current UX, and then we look at opportunities for improving consistency across other PRs

<ToggleGroupControlOption
key={ scale }
value={ scale }
label={ `${ scale }%` }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might make sense for the percentage string to be localized. In some languages, it might actually be displayed differently:

https://phrase.com/blog/posts/number-localization/#toc_5

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we localize other percentages across Gutenberg? If not, it may be better to split it to a separate PR to localize all percentages at the same time

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think, we are localizing other percentage implementations, here is the example for column block -

const widthWithUnit = Number.isFinite( width ) ? width + '%' : width;
We are directly using it without localizing.

I agree with @ciampo, to add all at once, so it does not block the scope of this PR.

Thank You,

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed issue #66298 regarding localizing percentage values.

@hbhalodia hbhalodia requested a review from tyxla October 21, 2024 09:13
@hbhalodia
Copy link
Contributor Author

Hi @mirka @t-hamano @ciampo @tyxla, I have implemented the suggestion for the utility function implementation. Let me know if I need to address anything with the scope of this issue and PR.

Thank You 🙇.

@ciampo
Copy link
Contributor

ciampo commented Oct 21, 2024

Looks like unit tests need updating — the ToggleGroupControl component implements radio semantics, and therefore each size option is not associated with the button role. I suggest using:

  • use screen.getByRole( 'radio', { name: accessibleName } ) to find the individual options
  • screen.getByRole( 'radio', { name: accessibleName } ).toBeChecked() or .not.toBeChecked() to explicitly assert which option is selected
  • or use screen.getByRole( 'radio', { name: accessibleName, checked: true } ) to implicitly add the "selected" check when querying for the option

@hbhalodia
Copy link
Contributor Author

Hi @ciampo, I would update the tests, Also to confirm, since we are not adding the reset button, should we remove the related test suite for the same?

Thank You,

@ciampo
Copy link
Contributor

ciampo commented Oct 21, 2024

Hi @ciampo, I would update the tests, Also to confirm, since we are not adding the reset button, should we remove the related test suite for the same?

Thank You,

I think so. We should make sure that we test the new logic highlighted by Aki in this comment

@ciampo
Copy link
Contributor

ciampo commented Oct 24, 2024

You may want to update this branch with the latest trunk commits in order to solve the CI error (the fix was merged in #66316)

@mirka mirka added Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). and removed [Type] Enhancement A suggestion for improvement. labels Oct 24, 2024
@kevin940726
Copy link
Member

As we've already entered the RC phase of 6.7, should we backport this PR to the 6.7 branch? Is this a fix of a regression introduced in the 6.7 cycle?

@t-hamano
Copy link
Contributor

Is this a fix of a regression introduced in the 6.7 cycle?

This PR is part of #65339 and looks like an enhancement to me, not a bug.

The following similar PR has already been backported, but this one is a bit more complicated than those two, so it might be safer not to backport it.

@mirka
Copy link
Member

mirka commented Oct 25, 2024

My bad, this one doesn't contain an accessibility bug like #65340 and #65346 do.

@mirka mirka added [Type] Enhancement A suggestion for improvement. and removed [Type] Bug An existing feature does not function as intended Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta labels Oct 25, 2024
Copy link
Contributor

@ciampo ciampo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All tests are passing, although I left a couple of minor suggestions.

@t-hamano / @mirka , could you take a final look to make sure it matched the behavior you settled on?

@hbhalodia hbhalodia requested a review from ciampo October 28, 2024 05:50
Copy link
Contributor

@ciampo ciampo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving since all feedback is addressed. I suggest waiting for @t-hamano 's review as well, to test the new overall behavior as he highlighted in a previous conversation.

And thank you for the great work and patience, @hbhalodia 🙏

Copy link
Contributor

@t-hamano t-hamano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update! I left one final small feedback, but I think it's ready to ship.

*
* @return {Object} The scaled width and height.
*/
function getScaledWidthAndHeight( scale, imageWidth, imageHeight ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: While there are no hard and fast rules, it is generally a good idea to put any sub-components, hooks, or functions used internally by a component before the default exported components.

So, it might be a good idea to move this function here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @t-hamano, Updated the PR to move the function before default export.

Thank You,

@ciampo
Copy link
Contributor

ciampo commented Oct 29, 2024

I guess we're good to merge?

@ciampo ciampo merged commit f73c3ad into WordPress:trunk Oct 29, 2024
61 checks passed
@github-actions github-actions bot added this to the Gutenberg 19.6 milestone Oct 29, 2024
karthick-murugan pushed a commit to karthick-murugan/gutenberg that referenced this pull request Nov 13, 2024
…ress#65386)

Co-authored-by: hbhalodia <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: kevin940726 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Block editor /packages/block-editor [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants