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

Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392

Merged
merged 50 commits into from
Aug 10, 2021

Conversation

aaronrobertshaw
Copy link
Contributor

@aaronrobertshaw aaronrobertshaw commented Jun 2, 2021

Part of: #28356

Description

  • Adds new ToolsPanel components
  • Uses the new components to refactor spacing block supports into a "Dimensions" panel.

The new panel component offers progressive discovery options for ToolsPanelItem wrapped components e.g. those provided through block supports.

It uses callbacks passed as props on the panel's children to check for values, handle child selection/deselection in the menu etc. In the case of block support controls, the onDeselect callback can reset the block attribute value.

The ToolsPanel automatically generates its menu from children that register themselves via the panel's context. The initial state managing which controls are displayed and therefore selected in the menu is based off the hasValue callback and an isShownByDefault prop.

A custom resetAll callback is passed to the panel and called when the associated menu item is selected. For the a panel displaying block support controls such as the dimensions panel, the resetAll callback will reset all block attributes for the dimensions related support.

G2 Components

The demo typography panel from the G2 project still needs a few underlying components and systems to be imported into Gutenberg. The approach in this PR works now and may unblock other block supports work.

New designs/G2 components for the individual block support controls can be iterated on separately.

How has this been tested?

Programmatic tests are available for the new panel:

  • npm run test-unit packages/components/src/tools-panel/test/

Storybook:

Manual testing is required for the updates switching the spacing block support UI to the new panel and "Dimensions" naming.

Testing Setup

The easiest block to test with is the group block.

  1. Turn on settings.spacing.customMargin under your theme.json file.
  2. Update the group block's block.json and turn on margin support under supports.spacing.
  3. Add new __experimentalDefaultControls flag under settings.spacing in block.json to specify which block support controls are displayed by default.

The example below configures only the padding control to show by default.

		"spacing": {
			"margin": true,
			"padding": true,
			"__experimentalDefaultControls": {
				"padding": true
			}
		},

Testing Instructions

The following instructions assume the padding control was enabled by default as per the snippet above.

  1. Edit a post, add a group block and select it
  2. Confirm there is a new "Dimensions" panel in the sidebar in place of the old "Spacing" panel
  3. Ensure the padding control is already displayed in the Dimensions panel
  4. Select margin control for display via the "Dimensions" panel's "more" menu
  5. Adjust padding and margin, confirming they update the block appropriately
  6. Open the more menu and toggle off the padding control
  7. Confirm the padding control is no longer shown
  8. Open the more menu once more and toggle off the margin control
  9. The margin control should be removed as well
  10. Toggle both controls back on and confirm they've been reset
  11. Adjust both padding and margin values, then select the "reset all" option from the more menu
  12. Confirm only the padding control is displayed but has been cleared
  13. Toggling margin back on and adjust both values again, then save
  14. Confirm margin and padding are displayed correctly on the frontend
  15. Reload the editor and confirm that the "Dimensions" panel has both fields displayed
  16. Choose the "Reset all" option from the panel menu again and save
  17. Reload both the editor and frontend checking the padding and margin were cleared
  18. Open the full site editor, open the Global Styles sidebar, then the "By block type" tab
  19. Expand the Group block's panel and confirm the "Dimensions" panel is present with both margin and padding shown by default.

Screenshots

With Default Controls

Without Default Controls

Types of changes

New feature.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • I've tested my changes with keyboard and screen readers.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

@aaronrobertshaw aaronrobertshaw added [Type] Enhancement A suggestion for improvement. [Feature] Block API API that allows to express the block paradigm. Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi labels Jun 2, 2021
@github-actions
Copy link

github-actions bot commented Jun 2, 2021

Size Change: -7.48 kB (-1%)

Total Size: 1.07 MB

Filename Size Change
build/annotations/index.min.js 2.93 kB +3 B (0%)
build/api-fetch/index.min.js 2.44 kB +1 B (0%)
build/block-directory/index.min.js 6.62 kB +1 B (0%)
build/block-directory/style-rtl.css 1.01 kB -8 B (-1%)
build/block-directory/style.css 1.01 kB -9 B (-1%)
build/block-editor/index.min.js 127 kB +251 B (0%)
build/block-editor/style-rtl.css 13.9 kB -142 B (-1%)
build/block-editor/style.css 13.9 kB -144 B (-1%)
build/block-library/blocks/audio/style-rtl.css 111 B -1 B (-1%)
build/block-library/blocks/audio/style.css 111 B -1 B (-1%)
build/block-library/blocks/button/editor-rtl.css 474 B -1 B (0%)
build/block-library/blocks/button/style-rtl.css 605 B +2 B (0%)
build/block-library/blocks/button/style.css 604 B +2 B (0%)
build/block-library/blocks/buttons/style-rtl.css 370 B -5 B (-1%)
build/block-library/blocks/buttons/style.css 370 B -5 B (-1%)
build/block-library/blocks/calendar/style-rtl.css 207 B -1 B (0%)
build/block-library/blocks/calendar/style.css 207 B -1 B (0%)
build/block-library/blocks/columns/editor-rtl.css 189 B -1 B (-1%)
build/block-library/blocks/columns/editor.css 188 B -2 B (-1%)
build/block-library/blocks/columns/style-rtl.css 474 B -1 B (0%)
build/block-library/blocks/columns/style.css 475 B -1 B (0%)
build/block-library/blocks/cover/editor-rtl.css 666 B -4 B (-1%)
build/block-library/blocks/cover/style-rtl.css 1.23 kB +3 B (0%)
build/block-library/blocks/cover/style.css 1.23 kB +2 B (0%)
build/block-library/blocks/embed/editor-rtl.css 488 B +2 B (0%)
build/block-library/blocks/embed/editor.css 488 B +2 B (0%)
build/block-library/blocks/embed/style-rtl.css 400 B -1 B (0%)
build/block-library/blocks/file/editor-rtl.css 300 B -1 B (0%)
build/block-library/blocks/freeform/editor-rtl.css 2.44 kB -4 B (0%)
build/block-library/blocks/freeform/editor.css 2.44 kB -5 B (0%)
build/block-library/blocks/gallery/editor-rtl.css 707 B +3 B (0%)
build/block-library/blocks/gallery/editor.css 706 B +1 B (0%)
build/block-library/blocks/gallery/style-rtl.css 1.05 kB -7 B (-1%)
build/block-library/blocks/gallery/style.css 1.05 kB -7 B (-1%)
build/block-library/blocks/group/editor-rtl.css 159 B -1 B (-1%)
build/block-library/blocks/group/editor.css 159 B -1 B (-1%)
build/block-library/blocks/html/editor-rtl.css 283 B +2 B (+1%)
build/block-library/blocks/html/editor.css 284 B +3 B (+1%)
build/block-library/blocks/image/editor-rtl.css 728 B -1 B (0%)
build/block-library/blocks/image/editor.css 728 B +1 B (0%)
build/block-library/blocks/image/style-rtl.css 482 B +1 B (0%)
build/block-library/blocks/image/style.css 487 B +2 B (0%)
build/block-library/blocks/latest-comments/style-rtl.css 284 B -2 B (-1%)
build/block-library/blocks/latest-comments/style.css 284 B -2 B (-1%)
build/block-library/blocks/latest-posts/style-rtl.css 528 B +2 B (0%)
build/block-library/blocks/latest-posts/style.css 527 B +3 B (+1%)
build/block-library/blocks/media-text/editor-rtl.css 266 B +3 B (+1%)
build/block-library/blocks/media-text/editor.css 263 B -1 B (0%)
build/block-library/blocks/media-text/style-rtl.css 488 B -4 B (-1%)
build/block-library/blocks/media-text/style.css 485 B -4 B (-1%)
build/block-library/blocks/more/editor-rtl.css 431 B -3 B (-1%)
build/block-library/blocks/more/editor.css 431 B -3 B (-1%)
build/block-library/blocks/navigation-link/editor.css 474 B +1 B (0%)
build/block-library/blocks/navigation/editor-rtl.css 1.67 kB -16 B (-1%)
build/block-library/blocks/navigation/editor.css 1.68 kB -11 B (-1%)
build/block-library/blocks/navigation/style-rtl.css 1.65 kB -2 B (0%)
build/block-library/blocks/navigation/style.css 1.64 kB -20 B (-1%)
build/block-library/blocks/page-list/editor.css 310 B -1 B (0%)
build/block-library/blocks/page-list/style-rtl.css 242 B +2 B (+1%)
build/block-library/blocks/page-list/style.css 242 B +2 B (+1%)
build/block-library/blocks/paragraph/style-rtl.css 248 B +1 B (0%)
build/block-library/blocks/post-author/editor-rtl.css 210 B +1 B (0%)
build/block-library/blocks/post-author/editor.css 210 B +1 B (0%)
build/block-library/blocks/post-author/style-rtl.css 182 B -1 B (-1%)
build/block-library/blocks/post-author/style.css 181 B -3 B (-2%)
build/block-library/blocks/post-content/editor-rtl.css 138 B -1 B (-1%)
build/block-library/blocks/post-content/editor.css 138 B -1 B (-1%)
build/block-library/blocks/post-featured-image/editor-rtl.css 412 B +74 B (+22%) 🚨
build/block-library/blocks/post-featured-image/editor.css 412 B +74 B (+22%) 🚨
build/block-library/blocks/post-featured-image/style-rtl.css 143 B +2 B (+1%)
build/block-library/blocks/post-featured-image/style.css 143 B +2 B (+1%)
build/block-library/blocks/post-template/editor-rtl.css 99 B -1 B (-1%)
build/block-library/blocks/post-template/editor.css 98 B -1 B (-1%)
build/block-library/blocks/post-template/style-rtl.css 378 B -1 B (0%)
build/block-library/blocks/post-template/style.css 379 B -1 B (0%)
build/block-library/blocks/pullquote/style-rtl.css 361 B -1 B (0%)
build/block-library/blocks/pullquote/style.css 360 B -1 B (0%)
build/block-library/blocks/pullquote/theme-rtl.css 167 B -2 B (-1%)
build/block-library/blocks/pullquote/theme.css 167 B -2 B (-1%)
build/block-library/blocks/query-title/editor-rtl.css 85 B -1 B (-1%)
build/block-library/blocks/query-title/editor.css 85 B -1 B (-1%)
build/block-library/blocks/quote/theme-rtl.css 220 B -1 B (0%)
build/block-library/blocks/quote/theme.css 222 B +1 B (0%)
build/block-library/blocks/rss/editor-rtl.css 202 B +1 B (0%)
build/block-library/blocks/rss/editor.css 204 B +2 B (+1%)
build/block-library/blocks/rss/style-rtl.css 289 B -1 B (0%)
build/block-library/blocks/rss/style.css 288 B -2 B (-1%)
build/block-library/blocks/search/editor-rtl.css 209 B -2 B (-1%)
build/block-library/blocks/search/editor.css 209 B -2 B (-1%)
build/block-library/blocks/search/style-rtl.css 368 B -4 B (-1%)
build/block-library/blocks/search/style.css 372 B -1 B (0%)
build/block-library/blocks/separator/style-rtl.css 250 B -1 B (0%)
build/block-library/blocks/separator/style.css 250 B -1 B (0%)
build/block-library/blocks/shortcode/editor-rtl.css 474 B -2 B (0%)
build/block-library/blocks/shortcode/editor.css 474 B -2 B (0%)
build/block-library/blocks/site-logo/editor-rtl.css 462 B -3 B (-1%)
build/block-library/blocks/site-logo/editor.css 464 B -1 B (0%)
build/block-library/blocks/site-logo/style-rtl.css 153 B -1 B (-1%)
build/block-library/blocks/site-logo/style.css 153 B -1 B (-1%)
build/block-library/blocks/site-tagline/editor-rtl.css 86 B -1 B (-1%)
build/block-library/blocks/site-tagline/editor.css 86 B -1 B (-1%)
build/block-library/blocks/site-title/editor-rtl.css 84 B -1 B (-1%)
build/block-library/blocks/site-title/editor.css 84 B -1 B (-1%)
build/block-library/blocks/social-link/editor-rtl.css 165 B +1 B (+1%)
build/block-library/blocks/social-links/editor-rtl.css 812 B +12 B (+2%)
build/block-library/blocks/social-links/editor.css 811 B +12 B (+2%)
build/block-library/blocks/social-links/style-rtl.css 1.33 kB -2 B (0%)
build/block-library/blocks/social-links/style.css 1.33 kB -4 B (0%)
build/block-library/blocks/spacer/editor-rtl.css 307 B -1 B (0%)
build/block-library/blocks/spacer/editor.css 307 B -1 B (0%)
build/block-library/blocks/table/editor-rtl.css 471 B -7 B (-1%)
build/block-library/blocks/table/editor.css 472 B -6 B (-1%)
build/block-library/blocks/table/style-rtl.css 481 B +1 B (0%)
build/block-library/blocks/table/style.css 481 B +1 B (0%)
build/block-library/blocks/template-part/editor-rtl.css 636 B +85 B (+15%) ⚠️
build/block-library/blocks/template-part/editor.css 635 B +85 B (+15%) ⚠️
build/block-library/blocks/video/editor-rtl.css 571 B +2 B (0%)
build/block-library/blocks/video/editor.css 572 B +2 B (0%)
build/block-library/common-rtl.css 1.29 kB +3 B (0%)
build/block-library/common.css 1.29 kB +2 B (0%)
build/block-library/editor-rtl.css 9.87 kB +34 B (0%)
build/block-library/editor.css 9.85 kB +17 B (0%)
build/block-library/index.min.js 147 kB +780 B (+1%)
build/block-library/reset-rtl.css 527 B +13 B (+3%)
build/block-library/reset.css 527 B +12 B (+2%)
build/block-library/style-rtl.css 10.2 kB -69 B (-1%)
build/block-library/style.css 10.2 kB -65 B (-1%)
build/block-library/theme-rtl.css 688 B -4 B (-1%)
build/block-library/theme.css 692 B -1 B (0%)
build/block-serialization-default-parser/index.min.js 1.3 kB -1 B (0%)
build/blocks/index.min.js 47.2 kB +1 B (0%)
build/components/index.min.js 217 kB +20.3 kB (+10%) ⚠️
build/components/style-rtl.css 15.8 kB -162 B (-1%)
build/components/style.css 15.8 kB -148 B (-1%)
build/compose/index.min.js 10.3 kB +54 B (+1%)
build/core-data/index.min.js 12.6 kB +112 B (+1%)
build/customize-widgets/index.min.js 10.8 kB +438 B (+4%)
build/customize-widgets/style-rtl.css 1.5 kB +11 B (+1%)
build/customize-widgets/style.css 1.49 kB +10 B (+1%)
build/data/index.min.js 7.21 kB -2 B (0%)
build/edit-navigation/index.min.js 13.9 kB +5 B (0%)
build/edit-navigation/style-rtl.css 3.1 kB -25 B (-1%)
build/edit-navigation/style.css 3.1 kB -24 B (-1%)
build/edit-post/classic-rtl.css 492 B +9 B (+2%)
build/edit-post/classic.css 494 B +11 B (+2%)
build/edit-post/index.min.js 30 kB -29.5 kB (-50%) 🏆
build/edit-post/style-rtl.css 7.18 kB -78 B (-1%)
build/edit-post/style.css 7.17 kB -73 B (-1%)
build/edit-site/index.min.js 26.5 kB +503 B (+2%)
build/edit-site/style-rtl.css 5.01 kB -30 B (-1%)
build/edit-site/style.css 5.01 kB -24 B (0%)
build/edit-widgets/index.min.js 16.6 kB +458 B (+3%)
build/edit-widgets/style-rtl.css 4.01 kB +23 B (+1%)
build/edit-widgets/style.css 4.02 kB +30 B (+1%)
build/editor/index.min.js 38.3 kB -213 B (-1%)
build/editor/style-rtl.css 3.92 kB -35 B (-1%)
build/editor/style.css 3.91 kB -45 B (-1%)
build/element/index.min.js 3.44 kB -2 B (0%)
build/format-library/index.min.js 5.72 kB -2 B (0%)
build/i18n/index.min.js 3.73 kB -1 B (0%)
build/list-reusable-blocks/style-rtl.css 838 B -4 B (0%)
build/list-reusable-blocks/style.css 838 B -4 B (0%)
build/nux/style-rtl.css 747 B +2 B (0%)
build/nux/style.css 743 B +1 B (0%)
build/primitives/index.min.js 1.06 kB -1 B (0%)
build/redux-routine/index.min.js 2.82 kB +2 B (0%)
build/reusable-blocks/index.min.js 2.56 kB +1 B (0%)
build/rich-text/index.min.js 10.8 kB +1 B (0%)
build/server-side-render/index.min.js 1.64 kB +2 B (0%)
build/shortcode/index.min.js 1.68 kB +1 B (0%)
build/widgets/index.min.js 6.48 kB -1 B (0%)
build/widgets/style-rtl.css 1.04 kB -4 B (0%)
build/widgets/style.css 1.04 kB -2 B (0%)
ℹ️ View Unchanged
Filename Size
build/a11y/index.min.js 1.12 kB
build/admin-manifest/index.min.js 1.46 kB
build/autop/index.min.js 2.28 kB
build/blob/index.min.js 673 B
build/block-library/blocks/archives/editor-rtl.css 61 B
build/block-library/blocks/archives/editor.css 60 B
build/block-library/blocks/archives/style-rtl.css 65 B
build/block-library/blocks/archives/style.css 65 B
build/block-library/blocks/audio/editor-rtl.css 58 B
build/block-library/blocks/audio/editor.css 58 B
build/block-library/blocks/audio/theme-rtl.css 125 B
build/block-library/blocks/audio/theme.css 125 B
build/block-library/blocks/block/editor-rtl.css 161 B
build/block-library/blocks/block/editor.css 161 B
build/block-library/blocks/button/editor.css 474 B
build/block-library/blocks/buttons/editor-rtl.css 315 B
build/block-library/blocks/buttons/editor.css 315 B
build/block-library/blocks/categories/editor-rtl.css 84 B
build/block-library/blocks/categories/editor.css 83 B
build/block-library/blocks/categories/style-rtl.css 79 B
build/block-library/blocks/categories/style.css 79 B
build/block-library/blocks/code/style-rtl.css 90 B
build/block-library/blocks/code/style.css 90 B
build/block-library/blocks/code/theme-rtl.css 131 B
build/block-library/blocks/code/theme.css 131 B
build/block-library/blocks/cover/editor.css 670 B
build/block-library/blocks/embed/style.css 400 B
build/block-library/blocks/embed/theme-rtl.css 124 B
build/block-library/blocks/embed/theme.css 124 B
build/block-library/blocks/file/editor.css 300 B
build/block-library/blocks/file/style-rtl.css 255 B
build/block-library/blocks/file/style.css 255 B
build/block-library/blocks/file/view.min.js 711 B
build/block-library/blocks/gallery/theme-rtl.css 122 B
build/block-library/blocks/gallery/theme.css 122 B
build/block-library/blocks/group/style-rtl.css 57 B
build/block-library/blocks/group/style.css 57 B
build/block-library/blocks/group/theme-rtl.css 93 B
build/block-library/blocks/group/theme.css 93 B
build/block-library/blocks/heading/editor-rtl.css 152 B
build/block-library/blocks/heading/editor.css 152 B
build/block-library/blocks/heading/style-rtl.css 76 B
build/block-library/blocks/heading/style.css 76 B
build/block-library/blocks/home-link/style-rtl.css 247 B
build/block-library/blocks/home-link/style.css 247 B
build/block-library/blocks/image/theme-rtl.css 124 B
build/block-library/blocks/image/theme.css 124 B
build/block-library/blocks/latest-posts/editor-rtl.css 137 B
build/block-library/blocks/latest-posts/editor.css 137 B
build/block-library/blocks/list/style-rtl.css 63 B
build/block-library/blocks/list/style.css 63 B
build/block-library/blocks/navigation-link/editor-rtl.css 474 B
build/block-library/blocks/navigation-link/style-rtl.css 94 B
build/block-library/blocks/navigation-link/style.css 94 B
build/block-library/blocks/navigation/view.min.js 2.84 kB
build/block-library/blocks/nextpage/editor-rtl.css 395 B
build/block-library/blocks/nextpage/editor.css 395 B
build/block-library/blocks/page-list/editor-rtl.css 310 B
build/block-library/blocks/paragraph/editor-rtl.css 157 B
build/block-library/blocks/paragraph/editor.css 157 B
build/block-library/blocks/paragraph/style.css 248 B
build/block-library/blocks/post-comments-form/style-rtl.css 140 B
build/block-library/blocks/post-comments-form/style.css 140 B
build/block-library/blocks/post-comments/style-rtl.css 360 B
build/block-library/blocks/post-comments/style.css 359 B
build/block-library/blocks/post-excerpt/editor-rtl.css 73 B
build/block-library/blocks/post-excerpt/editor.css 73 B
build/block-library/blocks/post-excerpt/style-rtl.css 69 B
build/block-library/blocks/post-excerpt/style.css 69 B
build/block-library/blocks/post-terms/style-rtl.css 73 B
build/block-library/blocks/post-terms/style.css 73 B
build/block-library/blocks/post-title/style-rtl.css 60 B
build/block-library/blocks/post-title/style.css 60 B
build/block-library/blocks/preformatted/style-rtl.css 103 B
build/block-library/blocks/preformatted/style.css 103 B
build/block-library/blocks/pullquote/editor-rtl.css 198 B
build/block-library/blocks/pullquote/editor.css 198 B
build/block-library/blocks/query-pagination-numbers/editor-rtl.css 122 B
build/block-library/blocks/query-pagination-numbers/editor.css 121 B
build/block-library/blocks/query-pagination/editor-rtl.css 270 B
build/block-library/blocks/query-pagination/editor.css 262 B
build/block-library/blocks/query-pagination/style-rtl.css 168 B
build/block-library/blocks/query-pagination/style.css 168 B
build/block-library/blocks/query/editor-rtl.css 131 B
build/block-library/blocks/query/editor.css 132 B
build/block-library/blocks/quote/style-rtl.css 169 B
build/block-library/blocks/quote/style.css 169 B
build/block-library/blocks/search/theme-rtl.css 64 B
build/block-library/blocks/search/theme.css 64 B
build/block-library/blocks/separator/editor-rtl.css 99 B
build/block-library/blocks/separator/editor.css 99 B
build/block-library/blocks/separator/theme-rtl.css 172 B
build/block-library/blocks/separator/theme.css 172 B
build/block-library/blocks/social-link/editor.css 165 B
build/block-library/blocks/spacer/style-rtl.css 48 B
build/block-library/blocks/spacer/style.css 48 B
build/block-library/blocks/table/theme-rtl.css 188 B
build/block-library/blocks/table/theme.css 188 B
build/block-library/blocks/tag-cloud/style-rtl.css 146 B
build/block-library/blocks/tag-cloud/style.css 146 B
build/block-library/blocks/template-part/theme-rtl.css 101 B
build/block-library/blocks/template-part/theme.css 101 B
build/block-library/blocks/term-description/editor-rtl.css 90 B
build/block-library/blocks/term-description/editor.css 90 B
build/block-library/blocks/text-columns/editor-rtl.css 95 B
build/block-library/blocks/text-columns/editor.css 95 B
build/block-library/blocks/text-columns/style-rtl.css 166 B
build/block-library/blocks/text-columns/style.css 166 B
build/block-library/blocks/verse/style-rtl.css 87 B
build/block-library/blocks/verse/style.css 87 B
build/block-library/blocks/video/style-rtl.css 173 B
build/block-library/blocks/video/style.css 173 B
build/block-library/blocks/video/theme-rtl.css 124 B
build/block-library/blocks/video/theme.css 124 B
build/block-serialization-spec-parser/index.min.js 3.06 kB
build/data-controls/index.min.js 831 B
build/date/index.min.js 31.8 kB
build/deprecated/index.min.js 738 B
build/dom-ready/index.min.js 576 B
build/dom/index.min.js 4.78 kB
build/escape-html/index.min.js 739 B
build/format-library/style-rtl.css 668 B
build/format-library/style.css 669 B
build/hooks/index.min.js 1.76 kB
build/html-entities/index.min.js 628 B
build/is-shallow-equal/index.min.js 710 B
build/keyboard-shortcuts/index.min.js 1.74 kB
build/keycodes/index.min.js 1.49 kB
build/list-reusable-blocks/index.min.js 2.07 kB
build/media-utils/index.min.js 3.08 kB
build/notices/index.min.js 1.07 kB
build/nux/index.min.js 2.31 kB
build/plugins/index.min.js 1.99 kB
build/priority-queue/index.min.js 791 B
build/react-i18n/index.min.js 924 B
build/reusable-blocks/style-rtl.css 256 B
build/reusable-blocks/style.css 256 B
build/token-list/index.min.js 848 B
build/url/index.min.js 1.95 kB
build/viewport/index.min.js 1.28 kB
build/warning/index.min.js 1.16 kB
build/wordcount/index.min.js 1.24 kB

compressed-size-action

@ramonjd
Copy link
Member

ramonjd commented Jun 3, 2021

This is great work, and acting as expected in the editor and frontend. I know it's WIP so take everything with an industrial-sized silo of giant-leech-killing salt.

I just had some observations, couched with all the "I'm no expert" and "I haven't been keeping up with background design/testing discussions" caveats. :)

When I click "Reset all" I can see the effect in the editor (the margins disappear). The panel collapses and the controls disappear too.

This is not the case on the story component demo where "Reset all" reinstates the controls.

Jun-03-2021 12-07-59

I think this is just a personal expectation so don't read anything into it, but when I reset a value I anticipate seeing the result of the action, that is, the reset/cleared input value.

Unchecking individual controls resets the value too, rather than toggling the UI only. I'm wondering how we can communicate this better. Toggling a check mark doesn't tell me what I'm about to do.

I only have my experience to draw upon, so it may be totally obvious to others 😆

Personally it took me a bit of clicking around to move through the panels and have to work out what this new, "mystery panel" was doing.

Jun-03-2021 11-49-15

Would it help accessibility if the entire body panel title toggled the ellipsis menu?

Screen Shot 2021-06-03 at 12 20 29 pm

Also have we thought about what would happen when we have multiple controls in the there, say padding and margin? What if we want to reset only one and not all? <= Retracting. My mistake.

Sorry for all the questions, I hope I'm not repeating what's already been addressed. Thanks!

@aaronrobertshaw
Copy link
Contributor Author

This is great work, and acting as expected in the editor and frontend. I know it's WIP so take everything with an industrial-sized silo of giant-leech-killing salt.

All feedback and testing is appreciated, thank you! 🙇

When I click "Reset all" I can see the effect in the editor (the margins disappear). The panel collapses and the controls disappear too.

This is intended however I'm certainly open to better approaches. The idea here was that the user is opting in or out of a specific feature not just toggling the display of a control. In this case, to opt out of a block support feature it needs to be reset.

This is not the case on the story component demo where "Reset all" reinstates the controls.

The trial typography panel in the G2 storybook maintains its own store and resets to an arbitrary default state that contains values for the controls. If the controls in this new panel have values they are shown. So the difference here is really what we are resetting to. In the demo an arbitrary state with values. In this PR with block supports, the block's attributes for the block support are undefined by default and hence don't show.

I think this is just a personal expectation so don't read anything into it, but when I reset a value I anticipate seeing the result of the action, that is, the reset/cleared input value.

This is a fair expectation. I'm not sure how we could communicate what is happening better when individual features are reset/toggled off. Perhaps the menu group label of "Display options" should actually reflect the purpose in this use case i.e. which block support feature is enabled.

Unchecking individual controls resets the value too, rather than toggling the UI only. I'm wondering how we can communicate this better. Toggling a check mark doesn't tell me what I'm about to do.

Good point. If we can make the menu as a whole clearer, that the options are opting in/out of a block support feature not toggling UI, perhaps the check mark also becomes clearer.

Personally it took me a bit of clicking around to move through the panels and have to work out what this new, "mystery panel" was doing.

I wonder if this would be easier if all or the majority of panels were switched to the progressive display approach?

Would it help accessibility if the entire body panel title toggled the ellipsis menu?

This sounds like an improvement to me although I'm not sure what issues that might present in terms of layout/positioning. Ultimately, for this first iteration I avoided going down that path, particularly given the demo G2 typography panel only relied on the ellipsis button itself to toggle.

Sorry for all the questions, I hope I'm not repeating what's already been addressed. Thanks!

Thanks again for the thorough feedback!

I think most of the issues raised can be boiled down to a difference of expectation i.e. opting in/out of a feature versus toggling display of a control on/off. Hopefully with a few tweaks we can improve the UX.

@jasmussen it would be great to get your thoughts and suggestions on this PR and some of these issues if you can spare some time 🙏

@jasmussen
Copy link
Contributor

This is potent! Thanks so much for working on this. It seems a small step, but it's such a key step. Here's what I see:

hey

Even in this state, it's working incredibly well, and almost exactly as I'd hoped it would:

  • Additional options are available in the more menu, adding one adds the control and lets you configure it.
  • Untoggling it is the same as clicking "reset" in the old system, in addition to removing the control.
  • Clicking "Reset all" clears all, expectedly.

One effect of this system surfaces an aspect not explicitly covered in the original ticket: the idea of default values. For example in a "Typography" panel shown in the block editor, I would expect "Font size" to be shown by default, and perhaps a future "Style preset" picker, but nothing else. If you need line height, letter spacing, letter case, any of those options, you would need to dig into the overflow menu to add them. However when you are in the Global Styles interface, we might want to surface all controls available at all times for all blocks, because that's where you set defaults.

In other words, the missing bit here is a "defaults" system. And since there's only "Padding" available for the Group block, at least for the foreseeable future I'd show it by default. This is not a knock on your work here at all — I expect additional dimension controls to land here needing to be explicitly added — it's just that the full potential probably isn't shown until we employ it for the Typography panel.

So how would a defaults system work with the "More" menu? Like so, I would expect:

  • Global styles always shows all design tools for blocks
  • Individual blocks have a specific subset of those controls shown by default
  • The checkbox in the More menu indicates "customized".
  • If you uncheck an option in the More menu, it both clears it, and if the control isn't in the list of defaults, removes the control from the panel.

Does that make sense?

@aaronrobertshaw
Copy link
Contributor Author

Great feedback as always @jasmussen, thank you. Glad this is in the ball park for what you imagined 👍

In other words, the missing bit here is a "defaults" system.

It would certainly round out the UX.

The current approach uses a callback on the block support feature's control component to determine if it has a value and therefore should be shown. A tweak to the intent of that callback would nearly have us there. It might fall down though when the context is different e.g. the block editor vs site editor's Global Styles.

Perhaps a simple prop on each control added to the panel could flag if it is to be displayed by default. When the panel generates the menu it can collect which are shown by default and use that when resetting. Under global styles they can all be set to true, and set as desired when in the block editor.

I expect additional dimension controls to land here needing to be explicitly added — it's just that the full potential probably isn't shown until we employ it for the Typography panel.

Yes. When the UI for the block support is created, each block support feature's control is conditionally added as a child to the panel. It's from those children the menu is created. At the moment only the padding, and margin support if following testing instructions, would show in the dimensions panel.

The typography panel was the next target if this PR showed promise. The panel can be styled to be a flex or grid container as well so the typography panel is a good chance to see how the controls can be laid out as they get toggled on and off.

So how would a defaults system work with the "More" menu? Like so, I would expect:

  • Global styles always shows all design tools for blocks
  • Individual blocks have a specific subset of those controls shown by default
  • The checkbox in the More menu indicates "customized".
  • If you uncheck an option in the More menu, it both clears it, and if the control isn't in the list of defaults, removes the control from the panel.

That all sounds good.

My only question would be do you see different block types needing to have different defaults for display?

What I mean by that is, take two block's, they both opt into the same block support feature e.g. font size. Would it be safe to say if font size was to be displayed by default it should be displayed by default for all block's opting into it? Or, could we have a situation where it should be shown by default for one block but not another?

I'll add an initial means of handling default display. Something to be able to be seen and played with at least.

@jasmussen
Copy link
Contributor

My only question would be do you see different block types needing to have different defaults for display?

That is an excellent question, and I think we maybe want that. You should almost never change the font in a single paragraph, but you might want to in a pullquote. Or a third party building a block might want to suggest it by default.

If per-block defaults (as opposed to per-panel defaults) is something we think we can add in the future, I think it's fine to not worry too much about that use case at the moment. The more important use case is the differentiation between block and global styles.

@aaronrobertshaw
Copy link
Contributor Author

@jasmussen I've had a go at adding default controls to this panel. It's pretty close though I don't think it's perfect.

There is just a small issue when you have default controls. They still need to be in the "more" menu so they can be reset. The menu item for these controls gets updated to have a check mark beside them when their value is set.

The problem comes when the control is empty and the user opens the menu. They see an unchecked menu item for the control. When that is clicked, nothing visually happens. They can then toggle it again to uncheck it and since it was empty it still appears that nothing happens.

DimensionsPanelWithDefaultsIssue

Do you think it would be ok to perhaps disable a default control's menu item when it doesn't have a value set?

Without a value there is no need to reset the control via the menu. Disabling it under those circumstances might prevent confusion as well as convey that the user doesn't get the choice as to whether that control is visible or not?

@jasmussen
Copy link
Contributor

Wonderful. Yep, we're down to the key remaining issue; the checkmark in the more menu serving as both a way to reset the control, and as a way to remove the control if it's not among the list of defaults.

I still think that behavior is key to keep, though, at the very least as a baseline we can learn from.

Let's imagine a Typography panel in the Paragraph that has the following:

  • Font
  • Font-size
  • Line-height
  • Appearance
  • Letter spacing
  • Letter case

Of those, only the Font-size is surfaced by default. So you click a paragraph, and it's present, even if it is unset. You can toggle it off which both removes the control, and unsets any value it might have had, or you can add it back.

In Global styles, all those controls would be surfaced by default. Here, you would also be able to toggle them off to reset any user customizations you may have made, and if you added a control back it would revert to the theme.json provided styles, or be unset, which ever is the case. In the global styles case, any controls you toggle off would also be back if you reloaded the page, even if those controls are unset.

So, how about this:

  • If you provide a padding by default in the dimensions panel, it would have a checkmark in the More menu, even if it was unset.
  • If you remove that checkmark to toggle off, or reset, the control, the control would be gone from that panel. But only until you deselect the block and select it again.
  • Any controls you add and then configure, would persist when you select the block again.
  • Any controls you add but don't configure, do not persist between selections, unless they are defaults.

Does that make sense?

@aaronrobertshaw
Copy link
Contributor Author

Great feedback, thanks @jasmussen!

I've updated the default controls to have a check mark beside them by default and also get removed when toggled off. This brings the panel's behaviour inline with the last description of requirements.

It would be good to confirm though how the "reset all" works.

Given that default controls can now be toggled off for display I think it makes sense that the behaviour is consistent between them and non-default controls. By that I mean, when resetting all controls, non-default controls get reset and toggled off. The current state of this PR is that when "reset all" is selected in the "more" menu, all controls are reset and removed from the panel. If you select a different block, then reselect the original block, you'll get the default controls displaying again.

If you are happy with the new functionality, this should be getting pretty close to just needing a final review.

@jasmussen
Copy link
Contributor

Thanks again so much for working on this, it really is quite crucial. By the way I'm seeing margin and padding hidden by default for the group; since there are so few options there, we might want to just show those by default.

Before I dive in I wanted to note that I suspect something like the typography panel will be an opportunity to refine the precise behavior of this system, and address any shortcomings there might be.

So, right now in this branch, unchecking a control:

  • ... clears the custom value, if any
  • and removes the control

That behavior appears to be the same as that of the original prototype, which works like this:

panel

In this prototype, "Reset all" does two things:

  • It clears any user values entered in the controls
  • It resets the configuration of the panel to show all default controls.

How would that translate to the Paragraph block, which showed only font-size by default? We can think of it as a "factory reset": if invoked on a Paragraph that has font, size, case and line-height customized, all values would be cleared and you'd only see the an empty font size control remain. So factory reset would clear all values, and reset the configuration of controls to show the defaults again.

I acknowledge that this might potentially be confusing since the checkmarks also serve as reset buttons, but I also think in practice it might feel just fine.

What do you think?

@aaronrobertshaw
Copy link
Contributor Author

By the way I'm seeing margin and padding hidden by default for the group; since there are so few options there, we might want to just show those by default.

I wasn’t making any calls on which blocks should enable which controls by default in this PR. Under the “Testing Setup” section in the PR description I added instructions on configuring the default controls.

In this prototype, “Reset all” does two things:

  • It clears any user values entered in the controls
  • It resets the configuration of the panel to show all default controls.

I'm assuming "this prototype" meant the original G2 prototype linked not this PR's?

This PR's approach takes a resetAll callback provided as a prop to the panel that can do whatever it wants. It can reset block support attributes to an arbitrary value or just clear them completely (this is the case for the padding/margin block supports).

It then toggles all controls off in the menu, thereby preventing them from being displayed, default control or not. That is, until the block is deselected, then selected again at which point the default controls would appear.

if invoked on a Paragraph that has font, size, case and line-height customized, all values would be cleared and you’d only see the an empty font size control remain.

That isn’t the case at the moment. You reset all, they all get reset and toggled off. This made the "reset all" option more consistent with the individual items which reset the value and toggle off a control.

So factory reset would clear all values, and reset the configuration of controls to show the defaults again.

This sounds much like the situation before the last round of changes only that now we can temporarily remove a default control. We end up with a different problem than that of the previous iteration. Instead of seemingly toggling a control that does nothing. Now resetting doesn’t get rid of a control so its behaviour is different than the individual menu items in terms of what it does to display of controls.

I can change the current approach of course. We only need to decide on how it should behave.

I acknowledge that this might potentially be confusing since the checkmarks also serve as reset buttons, but I also think in practice it might feel just fine.

What do you think?

I’m not 100% sold on the check marks and menu items being dual purpose. It feels like either way we go there is obscure behaviour. I think visually the panel UI looks much better, though functionally, it's less clear what does what, that additional controls even exist etc. Ultimately, if this is what is needed to provide expanded block functionality to users, it might just be the cost of doing so in the short term.

Thanks again for the feedback. This wouldn't be progressing without it 🙇

@jasmussen
Copy link
Contributor

jasmussen commented Jun 7, 2021

I wasn’t making any calls on which blocks should enable which controls by default in this PR. Under the “Testing Setup” section in the PR description I added instructions on configuring the default controls.

Ah, my bad, I got excited 😄

I'm assuming "this prototype" meant the original G2 prototype linked not this PR's?

Yes, sorry, this prototype: https://g2-components.xyz/?path=/story/designtools-presentation-typographypanel--default

This sounds much like the situation before the last round of changes only that now we can temporarily remove a default control. We end up with a different problem than that of the previous iteration. Instead of seemingly toggling a control that does nothing. Now resetting doesn’t get rid of a control so its behaviour is different than the individual menu items in terms of what it does to display of controls.

Thanks for your patience and clarity.

Yes, I personally think it's acceptable that the "reset all" toggle removes only some of the controls, so long as it also clears all of them. But more importantly, I'd be happy to try the simplest path forward, provided we believe we can go back and refine this. In other words, if we don't paint ourselves into a corner with a decision point here, it seems okay to try one thing and then revisit after, for example, trying it in the typography panel.

In this case, a reset all that just factory resets the panel — clears all values and corresponds to deselecting and re-selecting the block to reboot the defaults — is the best path forward.

I’m not 100% sold on the check marks and menu items being dual purpose. It feels like either way we go there is obscure behaviour. I think visually the panel UI looks much better, though functionally, it's less clear what does what, that additional controls even exist etc. Ultimately, if this is what is needed to provide expanded block functionality to users, it might just be the cost of doing so in the short term.

I think it's easy to get caught up in the intricacies of the behavior, and yes we definitely want to refine it. But it's also worth zooming out and walking through the flow and the problem we are solving:

  • We want all available features surfaced in global styles, as you are making sweeping changes.
  • ... but we don't want all controls shown by default in individual blocks. You should almost never need to change the font family of a single paragraph.
  • But when you do need to change the font family, say you are making a decorative heading, then we have the ellipsis menu to surface that field.

Defaults, in this case, are key: by allowing us to configure a default selection of controls on a per-block basis, we can start to create a slew of amazing new design tools that immediately become available across blocks, without weighing down the UI. As we move forward we can then fine-tune those defaults to get it just right, all the while enabling design tool work.

In practice I expect clearing values or "reset all" to be very rarely used tools; Figma doesn't even have them: if you want to clear a line-height, you select the value and delete it. So clear-tools have intentionally had their prominence reduced to match their value.

@aaronrobertshaw
Copy link
Contributor Author

Ah, my bad, I got excited

That's a good thing! It should mean we're making progress 🎉

I just imagined that we'd need a methodical approach to go over every block opting into each set of support features and deciding upon the appropriate defaults. A separate PR/s would help separate those discussions from how this panel worked in general.

Thanks for your patience and clarity.

It's been a team effort! I appreciate all of your guidance.

Yes, I personally think it's acceptable that the "reset all" toggle removes only some of the controls, so long as it also clears all of them.
...
In other words, if we don't paint ourselves into a corner with a decision point here, it seems okay to try one thing and then revisit after, for example, trying it in the typography panel.

I can make the change such that the "reset all" will not prevent a default control from displaying. My plan would be:

  • Change the function that toggles off all menu items to instead only toggle off the non-default controls
  • Leave the actual resetting of block support attributes as it is (the controls reflect those attributes so all will still be reset)

If we settle for all controls being removed when "reset all" is selected, nothing further needs to be done.

Either way, we can change to the alternate approach easy enough and definitely won't box ourselves into a corner.

Given it sounds like the first approach is the preferred option, I'm happy to make that change. Then once this PR lands, we can put the new panel through its paces updating the Typography panel.

I think it's easy to get caught up in the intricacies of the behavior, and yes we definitely want to refine it.

It is easy to not see the forest for the trees sometimes 🌳

For what it's worth, I am 100% sold on why we are reimagining the UI and what we're trying to achieve 🙂

@jasmussen
Copy link
Contributor

Given it sounds like the first approach is the preferred option, I'm happy to make that change. Then once this PR lands, we can put the new panel through its paces updating the Typography panel.

Sounds like a plan, I think it's worth trying it, especially if it's easyish to tune! Thank you.

For what it's worth, I am 100% sold on why we are reimagining the UI and what we're trying to achieve 🙂

💯

@aaronrobertshaw
Copy link
Contributor Author

The changes to the reset all functionality have been made. After the reset all menu item is selected all the default controls will be shown.

@jasmussen do you see anything else we need to improve from a UX perspective here or do we just need to get final approval on this PR and start using it for other block supports?

@jasmussen
Copy link
Contributor

From what I can glean in the conversation about this behavior, it seems like it's just about ready to merge. Though I wasn't able to fully test the defaults — my experimental-theme.json file is likely very out of date — are you able to provide a more complete theme.json example where margin and padding are both enabled by default?

That also leads me to my last question: these "shown by default" settings, are they per-panel, or per-block? Ideally they are per-block. For example in a future typography channel, we might only want to show font-size by default for the paragraph, but we might want to show both font-size, line-height and letter-case on the Pullquote block.

@aaronrobertshaw aaronrobertshaw merged commit 5a610d4 into trunk Aug 10, 2021
@aaronrobertshaw aaronrobertshaw deleted the try/block-supports-dimensions-panel branch August 10, 2021 23:44
@github-actions github-actions bot added this to the Gutenberg 11.3 milestone Aug 10, 2021
@ramonjd ramonjd mentioned this pull request Aug 11, 2021
7 tasks
@@ -88,9 +110,9 @@ function gutenberg_skip_spacing_serialization( $block_type ) {

// Register the block support.
WP_Block_Supports::get_instance()->register(
'spacing',
'dimensions',
Copy link
Member

Choose a reason for hiding this comment

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

This is the sort of thing I brought up at https://github.com/WordPress/gutenberg/pull/32499/files#r686747072

Isn't this problematic with existing spacing supports? What happens when core (WordPress 5.8) registers support for spacing and the plugin does not overwrite it as before but instead registers a different thing called dimensions?

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 more sense to keep things anchored to spacing for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the explanation @nosolosw, I think I understand my error now in not appreciating that core also register support under the same key.

I'll create a quick PR to change the key above from dimensions back to spacing and add an inline comment explaining why it is still spacing.

Regarding the comments on the PR introducing height block support I think there may be some confusion there, at least there is from my side, so I'll reply in more detail on that PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fix is up in: #34030

Thank you for catching this one!

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the quick turnaround, as always!

function gutenberg_register_spacing_support( $block_type ) {
$has_spacing_support = gutenberg_block_has_support( $block_type, array( 'spacing' ), false );

function gutenberg_register_dimensions_support( $block_type ) {
Copy link
Member

Choose a reason for hiding this comment

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

I have a second thought about this PR: I'm unsure whether we can rename a function that's been already shipped to WordPress core (see). Same for renaming the file: spacing.php to dimensions.php. These become "public APIs" once shipped and, generally, we can't remove them without notice: there's a deprecation process if need be, etc.

Would like thoughts from folks with more experience working with WordPress core: @gziolo @jorgefilipecosta @youknowriad

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree, it's similar to the above comment, even if this functions is marked "internal" in Core, so in theory we could rename, I think the file should be kept as spacing.php and the function renamed... Just stay consistent as long as the API is "spacing".

Copy link
Member

Choose a reason for hiding this comment

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

I'm fine using spacing for all.

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'm happy to rename this file back to spacing.php, restore the function name, and can do this tomorrow.

I was under the impression we wanted to collect all the current spacing and proposed dimensions support under a "dimensions" toolset. Hence, the rename and combining of both here, my apologies it's missed the mark.

Would it be better to revert this file back to the original spacing.php and create a new dimensions.php that will contain the height and width supports?

The UI created via dimensions.js for the block editor and dimensions-panel.js for site editor should be able to stay mostly as they are, correct?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd be in the camp of using "Dimensions" for the UI labels... but keeping "spacing" for the code because of the backward compatibility concerns.

Copy link
Member

Choose a reason for hiding this comment

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

Nothing to apologize for, that's what reviews are for!

Judging by the issues you linked, at the user/UI level, I presume the intention is to keep everything together, as you already did.

At the developer/code level, these are the boundaries that I see:

  • Keys in block.json & theme.json: as long as we use the same structure in both places, we should be fine. Either keeping everything under the spacing namespace or using spacing for the existing (margin, padding) and dimensions for the new (height, width).
  • Server hook: either having a single hook (spacing) or two (spacing and dimensions) should be fine as well, following what we decide for the keys.
  • Client hook: keeping a single UI hook to gather all props together looks simpler than trying to use SlotFills for this. Unlike the server code, we don't export the client hooks or the functions affected by this change, so keep the name "dimensions" instead of "spacing" is a style choice — it also matches well with what we use at the user level.

Within these boundaries, I believe the choices would be up to you. I can review that PR to help consolidate this code.

@ciampo
Copy link
Contributor

ciampo commented Aug 24, 2021

Hey @aaronrobertshaw , sorry if this is being tracked elsewhere, but is there any progress on the conversion to TypeScript for the ToolsPanel component? I'm happy to help with it, in case you need any!

@aaronrobertshaw
Copy link
Contributor Author

Hi @ciampo, a teammate started the conversion but we got caught up on other tasks. It will likely be a couple of days until I can revisit it. The draft PR can be found here: #34028

cc/ @glendaviesnz

@ciampo
Copy link
Contributor

ciampo commented Aug 24, 2021

Thank you @aaronrobertshaw , I'll keep an eye on it!

@youknowriad
Copy link
Contributor

I'm not sure how related exactly but I noticed that when moving the mouse (and doing nothing else), the ToolPanel components are constantly rerendering (seeing them highlighted using the React dev tools). This might potentially have some performance implications (probably not important for most but accumulation can make these things a problem)

@aaronrobertshaw
Copy link
Contributor Author

Thanks for raising this @youknowriad 👍

I believe this is actually an issue with the BoxControl rather than the ToolsPanel. The BoxControl currently saves the box visualizer data into the block's attributes and that appears to cause the re-renders.

When I hover and move the mouse around over other controls in other ToolsPanel components I don't see the rerendering.

There are open issues and PRs aimed at improving/fixing how the box control's visualizer data is handled.

GIF of what I see

ToolsPanelReRendering

If I've misunderstood the issue you were reporting please let me know.

@youknowriad
Copy link
Contributor

I think it's a different one, see now I have a group block selected and I move the mouse over the editor canvas, the tools panels keep flashing

Screen.Recording.2022-01-12.at.9.46.55.AM.mov

@youknowriad
Copy link
Contributor

@aaronrobertshaw Here's what I found so far:

  • The panels are rendering because the whole "Fill" is rerendering.
  • The fills for the tools panels are rendering because the "fillProps" are not shallow equal to the previous "fillProps"
  • The fill props for the ToolsPanel come from ToolsPanelContext context value. So basically the callbacks there are changing too often and might need to be memoized.

@aaronrobertshaw
Copy link
Contributor Author

Thanks for the extra details @youknowriad. I can see what you mean now.

Your explanation also covers why I didn't notice it when I tried to further isolate the issue by looking at the component within the storybook.

I've tried adding memoization to the ToolsPanelContext as well as the toggleItem and resetAllItems callbacks for the ToolsPanel, however, I'm not having much success reducing these rerenders. The BlockSupportToolsPanel also still rerenders despite wrapping its resetAll in useCallback as well.

Unfortunately, I'm out of time today but will pick this up again on Monday.

@aaronrobertshaw
Copy link
Contributor Author

The updates to the ToolsPanel to address rerenders has landed via #38037.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.