Skip to content

[Joy] Button API#29962

Merged
siriwatknp merged 40 commits intomui:masterfrom
siriwatknp:joy/button-theme
Dec 27, 2021
Merged

[Joy] Button API#29962
siriwatknp merged 40 commits intomui:masterfrom
siriwatknp:joy/button-theme

Conversation

@siriwatknp
Copy link
Member

@siriwatknp siriwatknp commented Nov 30, 2021

👉 Preview
👉 CodeSandbox

This PR will set a standard for the default style of each variant.

Styling APIs

  • variants (text, outlined, light, contained[default])
  • colors (primary[default], neutral, danger, info, success, warning)
  • sizes (sm, md[default], lg)

Others

  • TS spec
  • sx prop

I am really not sure about transition property. I think we can postpone the transition discussion in this PR and update later.


@mui-pr-bot
Copy link

mui-pr-bot commented Nov 30, 2021

Details of bundle changes

@mui/joy: parsed: -0.47% 😍, gzip: +0.40%

Generated by 🚫 dangerJS against bf364dd

@siriwatknp siriwatknp added package: joy-ui Specific to Joy UI. scope: button Changes related to the button. labels Nov 30, 2021
@danilo-leal
Copy link
Collaborator

Ended up doing some tweaks to other files (the default theme and variantUtils)! I think it would be nice to add to the component preview page what they would like in dark mode. I tried doing it with a dark background but that just doesn't trigger the variants changing to the dark color scheme 😅

@siriwatknp
Copy link
Member Author

Ended up doing some tweaks to other files (the default theme and variantUtils)! I think it would be nice to add to the component preview page what they would like in dark mode. I tried doing it with a dark background but that just doesn't trigger the variants changing to the dark color scheme 😅

Added!

> & {
breakpoints?: BreakpointsOptions;
spacing?: SpacingOptions;
components?: Components;
Copy link
Member Author

Choose a reason for hiding this comment

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

add components here to prevent dependency cycle.

@siriwatknp siriwatknp marked this pull request as ready for review December 3, 2021 02:30
Copy link
Member

@mnajdova mnajdova left a comment

Choose a reason for hiding this comment

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

From a styling perspective, I am only not sure about the warning color in light mode. It's too green for my eyes :)

* The border-radius of the component.
* @default 'default'
*/
roundness: PropTypes.oneOf(['default', 'lg', 'md', 'sm', 'xl', 'xs']),
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure about default as a value. I remember that at some point when we started on v5, we were actually replacing all default values for the props that we had. As far as I remember, the reasoning was the the default value is not a concrete value, we should rather have it be some specific value, like md. @mbrookes what are your thoughts on this?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, may be the roundness makes sense to not have default because some components can have different values. Ex, Switch might have initial roundness as xl whereas Button has 'md'.

Copy link
Member

Choose a reason for hiding this comment

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

Exactly, and you can probably use the same argument for each prop, the default for one component may not be the same as the default for another, so I wouldn't add it as a key.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agree that "the default" should be a given size available in the scale (e.g md or sm) instead of default being a plus one value. I think this is a general approach that should be applied to all props, not only border radius, though!

Copy link
Member

@mbrookes mbrookes Dec 8, 2021

Choose a reason for hiding this comment

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

Do we really need a prop for this? Is it common for a UI to have multiple buttons with different border radiuses? It seems like it should be configured through the theme. There might be an argument to be made for a "shape" prop (square, rounded, round), but there's a lot to be said for not adding props prematurely.

Copy link
Member Author

@siriwatknp siriwatknp Dec 15, 2021

Choose a reason for hiding this comment

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

The initial intention for having shadow and radius props for all components is for API consistency, so the experience of using is the same across components. However, after discussing with Danilo, it is better not to have these props because:

  • it encourages dev to make an inconsistent design which is not common for an application to have a different radius for a single component.
  • we already have sx prop API for one-time customization which can hook to the theme and use the token if needed.
  • more props, more maintenance afford.

shadow & radius props are removed, please review again.

@danilo-leal
Copy link
Collaborator

danilo-leal commented Dec 6, 2021

I am only not sure about the warning color in light mode.

Yeah, I'm also finding the yellow-600 on light mode not too great. But this is a tricky one because we're using the 600 shades as bg for the contained variants and if we lighten too much the yellows, the text will have to turn black to keep the contrast ratio which would make this a one-off case. I'll probably iterate a little more on the palette still - adding more colors, grey tones, etc.

@siriwatknp
Copy link
Member Author

siriwatknp commented Dec 6, 2021

the text will have to turn black to keep the contrast ratio which would make this a one-off case

I vote for bg yellow with black text. It makes more sense and shows that the variant approach is quite flexible.

Copy link
Member

@mnajdova mnajdova left a comment

Choose a reason for hiding this comment

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

Don’t forget to update the warning color 😀

### Manual

`yarn test:regresions:dev` will build all fixtures and render an overview page that lists all fixtures.
`yarn test:regressions:dev` will build all fixtures and render an overview page that lists all fixtures.
Copy link
Member Author

Choose a reason for hiding this comment

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

fix typo, nothing else.

@siriwatknp
Copy link
Member Author

Don’t forget to update the warning color 😀

Danilo has updated the colors, please check it out in the preview or sandbox. I think the colors should not block the PR in case we are not agreed on the color value.

@mbrookes
Copy link
Member

I think the colors should not block the PR in case we are not agreed on the color value.

Probably just as well - I've been resisting commenting on the rest of the colors besides blue. 😅

@siriwatknp siriwatknp requested a review from mnajdova December 16, 2021 07:20
@mnajdova
Copy link
Member

I think the colors should not block the PR in case we are not agreed on the color value.

But I thought this is the PR where we should discuss it, as it is about the button theme :D Should we look into the structure and API only? Could we then rename the PR title to: "[Joy] Buttom theme structure" or something similar?

@mnajdova
Copy link
Member

@siriwatknp @danilo-leal should we have clear steps about PR that we should expect when developing a Joy component? For example:

  1. functionality + API
  2. styles + theme

I would even say we should merge these two in one PR, otherwise, it's hard to know what to focus on when reviewing the PR, which means that we may even lose the opportunity to comment on something, just thinking that it is not a scope of the PR.

@michaldudak
Copy link
Member

michaldudak commented Dec 16, 2021

One thing I noticed is that on my screen (1.5x scaling) the button content doesn't look centered:

image

The distance between cap height and the top edge is 23px, but from baseline to the bottom edge there's just 20px. I'm not sure if anything can be done to work around this without affecting 1x and 2x screens, but I'll try to figure something out (I understand it may be harder for you if you don't have access to such a screen).


containedColor: `#fff`,
containedBg: `var(--joy-palette-${color}-500)`,
containedBg: `var(--joy-palette-${color}-600)`,
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 wondering if it wouldn't be better to supply these values to the background property (instead of background-color). It would allow developers to override the theme with gradients (or even images, but I wouldn't consider it a popular use case).

Copy link
Member Author

Choose a reason for hiding this comment

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

The idea of variant is to be applied globally (for most components). I think in case of gradient or image, it will be specific for component and as always developers can use the same theming API to do that. https://codesandbox.io/s/joy-cra-typescript-forked-be5uj?file=/src/App.tsx

However, if we see a real use case in the future we can also revisit this point.

@siriwatknp
Copy link
Member Author

siriwatknp commented Dec 21, 2021

@siriwatknp @danilo-leal should we have clear steps about PR that we should expect when developing a Joy component? For example:

  1. functionality + API
  2. styles + theme

I would even say we should merge these two in one PR, otherwise, it's hard to know what to focus on when reviewing the PR, which means that we may even lose the opportunity to comment on something, just thinking that it is not a scope of the PR.

What if we merge this PR and open another one with "[Joy] theme variant"? because variant is a global style and it is related to colors (I guess this will take a lot of time to refine to get the right one) and we can discuss only about variants (colors). This will give space for other components to continue to be developed on its own, otherwise we will be stuck in this PR.

Now other component PRs does not need to take color into account because it will follow the system.

I would like to merge this PR because I am stuck with a lot of change in this PR which I did not anticipate before. 🙏 eg. default theme structure & types.

@siriwatknp siriwatknp changed the title [Joy] Button theme [Joy] Button theme 1st iteration Dec 21, 2021
@danilo-leal
Copy link
Collaborator

Spent the last couple of days chewing on @mnajdova's suggestion and I think it makes sense. Especially as Joy components will follow the global styling defined on the theme. Thus, we could try handling the next components PRs separately:

  1. Component API and developer experience: questions like the ones brought up here: "why supporting an elevation prop?"; "sm or small?"; etc.
  2. Visual design: each token/variant specific value and general design iteration.

Each topic can have its rounds of iterations for nailing it down just right but trying to settle down on both at the same time is trickier. They definitely feed off each other but maybe it's better first to agree on a component API design - or at least on an initial draft to play around with - and later refine the visual aspect than the other way around.

So, we could change this pull request title to Button API or something similar?!

@siriwatknp
Copy link
Member Author

siriwatknp commented Dec 21, 2021

we could change this pull request title to Button API or something similar?!

Sounds good to me!

In the next component PR, I will try to make the scope smaller and more clear. (Actually, I have tried with the Button already 😂 I hope it will be easier for the next component)

@siriwatknp siriwatknp changed the title [Joy] Button theme 1st iteration [Joy] Button API Dec 21, 2021
Copy link
Member

@mnajdova mnajdova left a comment

Choose a reason for hiding this comment

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

I spotted a few other uses of default in the theme, could you check them? The Button's API itself looks good to me 👍

Copy link
Member

@mnajdova mnajdova left a comment

Choose a reason for hiding this comment

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

I am happy with the changes 👌

@siriwatknp siriwatknp merged commit 1c02cf8 into mui:master Dec 27, 2021
@hbjORbj hbjORbj mentioned this pull request Mar 9, 2022
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

package: joy-ui Specific to Joy UI. scope: button Changes related to the button.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants