Skip to content

Toolbar: Add unstyled variant #55139

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.

Sign up for GitHub

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

Merged
brookewp merged 11 commits into from
Oct 12, 2023
Merged

Toolbar: Add unstyled variant #55139

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
b0e8e1f
Toolbar: Add unstyled variant
brookewp Oct 6, 2023
4b2cafc
Add variants to block editor and remove workarounds
brookewp Oct 6, 2023
b2c3662
Update stories
brookewp Oct 6, 2023
b8abb3f
Add test for new variant
brookewp Oct 6, 2023
084f41f
Update changelog
brookewp Oct 6, 2023
b53ea1d
Memoize toolbar context
brookewp Oct 6, 2023
a5e772a
Clean up and improve CSS
brookewp Oct 6, 2023
a542f36
Add to README and update phrasing
brookewp Oct 11, 2023
4de2267
Implement feedback to simplify and optimize
brookewp Oct 11, 2023
fc0c029
Rename and simplify story by reusing default args
brookewp Oct 11, 2023
74d2c30
Merge branch 'trunk' into add/toolbar-variant
brookewp Oct 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Memoize toolbar context
  • Loading branch information
@brookewp
brookewp committed Oct 6, 2023
commit b53ea1d07a39b3c6380f6247dae277fc02f9cf0d
34 changes: 17 additions & 17 deletions packages/components/src/toolbar/toolbar/index.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ import type { ForwardedRef } from 'react';
/**
* WordPress dependencies
*/
import { forwardRef } from '@wordpress/element';
import { forwardRef, useMemo } from '@wordpress/element';
import deprecated from '@wordpress/deprecated';

/**
Expand All @@ -19,21 +19,6 @@ import type { ToolbarProps } from './types';
import type { WordPressComponentProps } from '../../context';
import { ContextSystemProvider } from '../../context';

const CONTEXT_SYSTEM_VALUE = ( variant: string | undefined ) => {
if ( variant !== undefined ) {
return {};
}

return {
DropdownMenu: {
variant: 'toolbar',
},
Dropdown: {
variant: 'toolbar',
},
};
};

function UnforwardedToolbar(
{
className,
Expand All @@ -43,6 +28,21 @@ function UnforwardedToolbar(
}: WordPressComponentProps< ToolbarProps, 'div', false >,
ref: ForwardedRef< any >
) {
const CONTEXT_SYSTEM_VALUE = useMemo( () => {
Copy link
Member

@tyxla tyxla Oct 9, 2023

Choose a reason for hiding this comment

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

I'd encourage changing CONTEXT_SYSTEM_VALUE to contextSystemValue since this is no longer a module constant.

Copy link
Contributor Author

@brookewp brookewp Oct 11, 2023

Choose a reason for hiding this comment

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

I'm also unfamiliar with the term 'module constants' so thanks for suggesting! My assumption on this change is now there is more than one possible return value vs. before. Is that correct, or is it based on something else?

Copy link
Contributor

@ciampo ciampo Oct 11, 2023

Choose a reason for hiding this comment

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

This simply a naming convention: constant values variables are usually UPPERCASE_LIKE_THIS. That was the case for CONTEXT_SYSTEM_VALUE before this PR.

But since it's been moved inside the react component's function, it's no longer a constant. Marin is suggesting that we change the casing (if that's even a word) to a more traditional camelCase

Copy link
Member

@tyxla tyxla Oct 11, 2023

Choose a reason for hiding this comment

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

Thanks for elaborating, @ciampo, that's exactly what I meant.

if ( variant !== undefined ) {
return {};
}

return {
DropdownMenu: {
variant: 'toolbar',
},
Dropdown: {
variant: 'toolbar',
},
};
}, [ variant ] );
Copy link
Member

@tyxla tyxla Oct 9, 2023

Choose a reason for hiding this comment

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

CONTEXT_SYSTEM_VALUE will be recalculated on every value, regardless what it is. At the same time, we only care about its declaration if it changes from undefined to any other value, or the other way around.

So, to micro-optimize, I'd recommend declaring that as a value above the useMemo and using that instead of variant:

Suggested change
const CONTEXT_SYSTEM_VALUE = useMemo( () => {
if ( variant !== undefined ) {
return {};
}
return {
DropdownMenu: {
variant: 'toolbar',
},
Dropdown: {
variant: 'toolbar',
},
};
}, [ variant ] );
const isVariantDefined = variant !== undefined;
const CONTEXT_SYSTEM_VALUE = useMemo( () => {
if ( isVariantDefined ) {
return {};
}
return {
DropdownMenu: {
variant: 'toolbar',
},
Dropdown: {
variant: 'toolbar',
},
};
}, [ isVariantDefined ] );

Copy link
Contributor Author

@brookewp brookewp Oct 11, 2023

Choose a reason for hiding this comment

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

Thanks for sharing! I'm unfamiliar with useMemo and implemented it due to a console.warn. So, I'm unsure if I fully understand the difference. 🤔 If you have time to share more or if you know of any examples I could look into to understand further, I'd appreciate it!

Copy link
Contributor

@ciampo ciampo Oct 11, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

The code inside useMemo gets executed only when any of its dependencies change — it is therefore useful when we want to only re-compute something when absolutely necessary, and otherwise use the result from past computations. This is particularly useful for a bunch of reasons:

  • it's great when we need to compute something particularly complex / slow to calculate (not this case)
  • since React components re-render any time one of their props change, by memoizing a value we can try to reduce that number of rerenders. In fact, without useMemo we would be technically creating a new, different object every time

The react docs are a good start if you're interested in learning more

Copy link
Member

@tyxla tyxla Oct 11, 2023

Choose a reason for hiding this comment

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

What @ciampo said 👍

In terms of how often it recomputes, useMemo() is very similar to useEffect or useCallback - it will be recomputed only if one of the dependencies change, so we always strive to keep the dependencies as minimal and as static as possible.

Let's consider an example. If variant is a dependency, then the useMemo() will be recompute every time variant changes, for example, if variant was A and gets changed to B, or if it was B and was changed to undefined. However, if we declare const isVariantDefined = variant !== undefined; and then use isVariantDefined as a dependency, useMemo will recompute only if isVariantDefined changes from undefined to anything else, or from anything else to undefined. That means, if variant changes from A to B, isVariantDefined won't change, therefore useMemo() won't recompute.

That being said, it's a micro-optimization, and likely won't have a measurable impact, unless we change the variant prop often for some reason.


if ( ! label ) {
deprecated( 'Using Toolbar without label prop', {
since: '5.6',
Expand All @@ -67,7 +67,7 @@ function UnforwardedToolbar(
);

return (
<ContextSystemProvider value={ CONTEXT_SYSTEM_VALUE( variant ) }>
<ContextSystemProvider value={ CONTEXT_SYSTEM_VALUE }>
<ToolbarContainer
className={ finalClassName }
label={ label }
Expand Down