-
Notifications
You must be signed in to change notification settings - Fork 10
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
[WB-1814.7] Refactor Modal to use semantic colors #2468
Conversation
…ticColors. Restructure theme contract.
🦋 Changeset detectedLatest commit: 473de27 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Size Change: +81 B (+0.08%) Total Size: 97.6 kB
ℹ️ View Unchanged
|
A new build was pushed to Chromatic! 🚀https://5e1bf4b385e3fb0020b7073c-eyjmktobvn.chromatic.com/ Chromatic results:
|
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.
note: this file didn't support theming yet, so I used the HOC available for that.
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.
note: Also applied theming here, but using the hook in this case.
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.
It's great we have the option to apply theming both ways, nice job 😄
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.
note: Restructured the theme contract to split it by component, then separate tokens by semantic category:
e.g.
// theme.component.category.property
theme.header.color.background
theme.footer.spacing.gap
@@ -5,6 +5,7 @@ export {default as useScopedTheme} from "./hooks/use-scoped-theme"; | |||
export { | |||
default as withScopedTheme, | |||
type WithThemeProps, | |||
type WithoutTheme, |
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.
note: I had to expose this in order to use withScopedTheme
in other WB packages, otherwise TS would complain b/c it needed that type for inferring the correct types in the HOC consumer (ModalBackdrop in this case).
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
npm Snapshot: Published🎉 Good news!! We've packaged up the latest commit from this PR (44b6399) and published all packages with changesets to npm. You can install the packages in webapp by running: ./services/static/dev/tools/deploy_wonder_blocks.js --tag="PR2468" Packages can also be installed manually by running: pnpm add @khanacademy/wonder-blocks-<package-name>@PR2468 |
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.
Looks good, left some non-blocking questions!
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.
It's great we have the option to apply theming both ways, nice job 😄
@@ -153,41 +153,40 @@ const small = "@media (max-width: 767px)"; | |||
|
|||
const themedStylesFn: ThemedStylesFn<ModalDialogThemeContract> = (theme) => ({ | |||
header: { | |||
boxShadow: `0px 1px 0px ${theme.color.shadow.default}`, | |||
boxShadow: `0px 1px 0px ${theme.header.color.border}`, |
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.
(for later): Do you think box shadow values should belong in the theme?
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.
Yes, but I'm planning to address first global elevation
tokens in a separate ticket. I'll add a TODO comment here.
outlineWidth: theme.border.width, | ||
outlineColor: theme.border.color, | ||
outlineWidth: theme.root.border.width, | ||
outlineColor: theme.panel.color.border, |
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.
Would it make sense for this to be theme.root.color.border
? Or for the outlineWidth/borderRadius to be theme.panel.border.width
and theme.panel.border.radius
so using root or panel styles is consistent?
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 originally used theme.panel.border.*
but noticed that this value is shared with the Dialog component too, and that's where I moved it to root
. The border
color token is specific to panel
in this case, and that's why I moved it here. I'll move it to the root
object to make it more consistent.
* Building blocks | ||
*/ | ||
backdrop: { | ||
color: { |
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.
For the theme component tokens with building blocks, do you think it's helpful to keep the additional separation between color
,spacing
, etc? Curious what you think!
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 still see benefit in terms of readability and consistency. Also portability in case we need to refactor or move stuff around.
border: semanticColor.border.focus, | ||
}, | ||
spacing: { | ||
paddingBlockEnd: spacing.xLarge_32, |
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.
For token names, what do you think about naming the tokens so that they aren't specific to how it is used in css? That way, if we were to change how we apply the spacing value in the component, we wouldn't have to rename the token!
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 think it makes sense in this case as it can be renamed to gap
(not directly related to the css prop). In other cases, it might be trickier where tokens are directly associated to specific properties (e.g. the header
padding).
root: { | ||
// TODO(WB-1852): Remove light variant. | ||
color: { | ||
inverse: { |
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 there a reason we don't need the background and foreground defined for the default case (non-inverse)?
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 reason at all, but I don't see why we shouldn't have that.
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.
Left you a few additional questions! Thanks for doing all of this theming work, @jandrade!
display: "flex", | ||
flexDirection: "column", | ||
minHeight: 66, | ||
padding: `${theme.spacing.header.medium}px ${theme.spacing.header.large}px`, | ||
padding: `${theme.header.spacing.paddingBlockMd}px ${theme.header.spacing.paddingInlineMd}px`, |
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.
Could we put the px
unit into a variable so it could be easily replaced later (for rem
or em
)?
[small]: { | ||
paddingRight: theme.spacing.header.large, | ||
paddingRight: theme.header.spacing.titlePaddingRightSm, |
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 padding appears to have gone from large
to sm
, is that intentional?
paddingInlineSm: spacing.medium_16, | ||
gap: spacing.xSmall_8, | ||
titlePaddingRightMd: spacing.medium_16, | ||
titlePaddingRightSm: spacing.xLarge_32, |
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.
Should this be titlePaddingRightXl
?
titlePaddingRightSm: spacing.xLarge_32, | ||
}, | ||
}, | ||
panel: { |
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 like how you grouped these styles by component!
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2468 +/- ##
============================
============================
Continue to review full report in Codecov by Sentry.
|
…#2470) ## Summary: Next step is to refactor the `Popover`, `Tooltip` and `Toolbar` packages to use semantic colors. ### Implementation plan: 1. #2439 2. #2440 3. #2441 4. #2446 5. #2449 6. #2464 7. #2468 8. Popover, Tooltip, Toolbar (current PR) 9. Dropdown 10. Clickable, Pill Issue: WB-1814 ## Test plan: Verify that the Modal Chromatic snapshots are mostly unchanged. Author: jandrade Reviewers: beaesguerra Required Reviewers: Approved By: beaesguerra Checks: ✅ Chromatic - Get results on regular PRs (ubuntu-latest, 20.x), ✅ Test / Test (ubuntu-latest, 20.x, 2/2), ✅ Test / Test (ubuntu-latest, 20.x, 1/2), ✅ Lint / Lint (ubuntu-latest, 20.x), ✅ Check build sizes (ubuntu-latest, 20.x), ✅ Publish npm snapshot (ubuntu-latest, 20.x), ✅ Chromatic - Build and test on regular PRs / chromatic (ubuntu-latest, 20.x), ✅ Check for .changeset entries for all changed files (ubuntu-latest, 20.x), ⏭️ Chromatic - Skip on Release PR (changesets), ✅ Prime node_modules cache for primary configuration (ubuntu-latest, 20.x), ✅ gerald, ⏭️ dependabot Pull Request URL: #2470
## Summary: - Migrate Clickable and Pill to use semantic colors - Add `All Variants` story to Pill ### Implementation plan: 1. #2439 2. #2440 3. #2441 4. #2446 5. #2449 6. #2464 7. #2468 8. #2470 9. Clickable, Pill (current PR) 10. Dropdown Issue: WB-1814 ## Test plan: Navigate to the `Clickable` and `Pill` stories in Storybook and verify that the colors are correct. Author: jandrade Reviewers: jandrade, beaesguerra Required Reviewers: Approved By: beaesguerra Checks: ✅ Chromatic - Get results on regular PRs (ubuntu-latest, 20.x), ✅ Test / Test (ubuntu-latest, 20.x, 2/2), ✅ Test / Test (ubuntu-latest, 20.x, 1/2), ✅ Lint / Lint (ubuntu-latest, 20.x), ✅ Check build sizes (ubuntu-latest, 20.x), ✅ Publish npm snapshot (ubuntu-latest, 20.x), ✅ Chromatic - Build and test on regular PRs / chromatic (ubuntu-latest, 20.x), ✅ Check for .changeset entries for all changed files (ubuntu-latest, 20.x), ✅ Prime node_modules cache for primary configuration (ubuntu-latest, 20.x), ⏭️ Chromatic - Skip on Release PR (changesets), ✅ gerald, ⏭️ dependabot Pull Request URL: #2472
…2474) ## Summary: Last PR that migrates the remaining components to use semantic colors. - Added `All Variants` stories to `ActionItem` and `OptionItem`. - Refactored `ActionItem` and `OptionItem` to use semantic colors. - Also refactored `ActionMenu`, `SingleSelect`, `MultiSelect` and `Combobox` to use semantic colors. - Simplified the styles in `ActionMenuOpenerCore` to use a single static StyleSheet instance (instead of generating another one in runtime). ### Implementation plan: 1. #2439 2. #2440 3. #2441 4. #2446 5. #2449 6. #2464 7. #2468 8. #2470 9. #2472 10. Dropdown (current PR) Issue: WB-1814 ## Test plan: Verify that all the dropdown stories are still working as expected. Author: jandrade Reviewers: jandrade, beaesguerra Required Reviewers: Approved By: beaesguerra Checks: ✅ Chromatic - Get results on regular PRs (ubuntu-latest, 20.x), ✅ Lint / Lint (ubuntu-latest, 20.x), ✅ Test / Test (ubuntu-latest, 20.x, 2/2), ✅ Test / Test (ubuntu-latest, 20.x, 1/2), ✅ Check build sizes (ubuntu-latest, 20.x), ✅ Publish npm snapshot (ubuntu-latest, 20.x), ✅ Chromatic - Build and test on regular PRs / chromatic (ubuntu-latest, 20.x), ✅ Check for .changeset entries for all changed files (ubuntu-latest, 20.x), ⏭️ Chromatic - Skip on Release PR (changesets), ✅ Prime node_modules cache for primary configuration (ubuntu-latest, 20.x), ⏭️ dependabot, ✅ gerald Pull Request URL: #2474
Summary:
Next step is to refactor the
Modal
package to use semantic colors.Besides the migration, this PR also includes the following changes:
Implementation plan:
Issue: WB-1814
Test plan:
Verify that the Modal Chromatic snapshots are mostly unchanged.
URL:
/?path=/docs/packages-modal-onepanedialog--docs&globals=viewport:desktop