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

[Typography] Migrate styles to emotion #23841

Merged
merged 34 commits into from Dec 18, 2020

Conversation

DanailH
Copy link
Member

@DanailH DanailH commented Dec 4, 2020

This PR migrates the Typography component to use the v5 styled engine. Steps necessary for the changes.

  1. Convert the styles definition to use experimentalStyled for each of the slots in the component (we only have the Root here).
  2. Create overridesResolver function that will be used as a parameter for the experimentalStyled utility for the Root that will map how the styles overrides will be added to the styles of the component, based on the provided props.
  3. Create useComponentNameClasses hook, that will append the correct global and input classes on the component based on the props. We recommend you extract the global classes under a componentNameClasses object, that can be further used by developers and for updating the tests.
  4. Use the useThemeProps hook, for getting default props from he theme.components options.
    const props = useThemeProps({ props: inProps, name: 'MuiTypography' });
  5. Map all state and props to the stylesProps key, and use this in the experimentalStyled utility.
  6. Finally, if the component implemented the component prop, use emotion's (styled-components's) as prop for forwarding this prop.

For updating the tests, your ill need to do the following:

  1. Replace the describeConformance with describeConformanceV5. You will need in addition to provide the following options: muiName and testVariantProps for testing the theme.components options on the updated component.
  2. Import and use the componentnameClasses object and use it trough out the tests, whenever the classes are required.

@DanailH DanailH requested a review from mnajdova December 4, 2020 15:02
@mui-pr-bot
Copy link

mui-pr-bot commented Dec 4, 2020

@material-ui/core: parsed: +0.28% , gzip: +0.39%
@material-ui/lab: parsed: +7.06% , gzip: +10.81%

Details of bundle changes

Generated by 🚫 dangerJS against ff81d3e

@@ -8,17 +8,17 @@ import MuiLink from '@material-ui/core/Link';
import { useUserLanguage } from 'docs/src/modules/utils/i18n';

const NextComposed = React.forwardRef(function NextComposed(props, ref) {
const { as, href, ...other } = props;
const { linkAs, href, ...other } = props;
Copy link
Member

Choose a reason for hiding this comment

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

We had conflict here with the as prop from emotion.

Copy link
Member

Choose a reason for hiding this comment

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

I think we should document the props that are now intercepted by emotion. It is a breaking change if you were passing these through. Maybe add a section in the changelog that only lists affected components and once we migrated all we just give the general advise that if you had <MuiComponent component={SomeOtherComponent} emotionProp1 emotionProp2 />, that these are no longer passed to SomeOtherComponent

Copy link
Member

Choose a reason for hiding this comment

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

Will we need to update the Next.js and Gatsby examples for the conflict?

Copy link
Member

Choose a reason for hiding this comment

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

@eps1lon will add an entry in the migration-v4.md for it. @oliviertassinari good call, let me check if the examples need to be updated.

Copy link
Member

Choose a reason for hiding this comment

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

Added migration entry - d764665 we can extend it with more props if there are any. At this moment this is the only one I could notice not being propagated.

Both nextjs examples have been updated. I didn't noticed anything worth updating in the gatsby examples.

'span',
{},
{ muiName: 'MuiTypography' },
)((props) => ({
Copy link
Member

Choose a reason for hiding this comment

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

I like how the styles are much more compact :)

Copy link
Member

Choose a reason for hiding this comment

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

To be fair, most of the reduction comes from the missing inline documentation. Last time I asked, core members did seem to rely on them so I'm not sure the new compactness a good thing (can't find the poll in slack anymore). Personally, I'm happy with getting rid of them to simplify documentation but there are some unintended side-effects to this change.

Copy link
Member

Choose a reason for hiding this comment

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

Agree, that's true too, but still I like how all variants are simply defined by one line:

...(props.styleProps.variant && props.theme.typography[props.styleProps.variant]),

at the same time allowing us to support dynamic variants out of the box :)

{ muiName: 'MuiTypography' },
)((props) => ({
margin: 0,
...(props.styleProps.variant && props.theme.typography[props.styleProps.variant]),
Copy link
Member

Choose a reason for hiding this comment

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

With this line we are enabling direct variant override for something defined in the theme 🚀 This has been a feature requested in #22257

Copy link
Member

Choose a reason for hiding this comment

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

Awesome.

@mnajdova

This comment has been minimized.

@mnajdova
Copy link
Member

mnajdova commented Dec 7, 2020

Note to me: after 0cad18a the proptypes generation is not including the className and component props. :\

Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

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

@oliviertassinari now that we do not use the withStyles wrapper I guess we need to have these tests per component.

@mnajdova Makes sense.


Considering the last feedback from @eps1lon, I think that it's interesting that we only migrate the component, without handling the documentation nor the unstyled component. How about we use the Typography to determine the best course of action? We try to do the changes in isolation. I have to agree with Sebastian that if we aim to ask for help from the community, the smaller the migration tasks are, the most likely they will be successful.

But maybe we don't even need an unstyled Typography component?

@eps1lon
Copy link
Member

eps1lon commented Dec 7, 2020

Known issues: currently the as prop is not respected.

Why is this an issue? We already have the component prop which does the same thing. I don't think we want to have two props for the same concern.

@mnajdova
Copy link
Member

mnajdova commented Dec 7, 2020

Why is this an issue? We already have the component prop which does the same thing. I don't think we want to have two props for the same concern.

Yep, it was fixed, we use the component prop, but leverage the as prop from emotion/styled-components for generating the correct tag

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Dec 8, 2020
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Dec 8, 2020
Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

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

Something seems off about the styling approach.

For example, the <nav> in https://deploy-preview-23841--material-ui.netlify.app/components/breadcrumbs/#basic-breadcrumbs now has one additional class (css-znp3um-MuiTypography for me). In addition, only one of the Typography related classes has a declaration:

  • MuiTypography-root - No styles applied
  • MuiTypography-colorTextSecondary - No styles applied
  • MuiTypography-body1 - No styles applied
  • MuiBreadcrumbs-root - No styles applied
  • css-znp3um-MuiTypography - Styles applied

Before only MuiBreadcrumbs-root had no styles applied (because it is empty).

The reason I find this problematic: It is now not apparent from the devtools which styles come from which class (necessary information since
we consider CSS classes and their names part of the public API). We would now need documentation for our styles declaration and the source code is way too syntax/API heavy.

Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

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

Something seems off about the styling approach.

For example, the <nav> in https://deploy-preview-23841--material-ui.netlify.app/components/breadcrumbs/#basic-breadcrumbs now has one additional class (css-znp3um-MuiTypography for me). In addition, only one of the Typography related classes has a declaration:

  • MuiTypography-root - No styles applied
  • MuiTypography-colorTextSecondary - No styles applied
  • MuiTypography-body1 - No styles applied
  • MuiBreadcrumbs-root - No styles applied
  • css-znp3um-MuiTypography - Styles applied

Before only MuiBreadcrumbs-root had no styles applied (because it is empty).

The reason I find this problematic: It is now not apparent from the devtools which styles come from which class (necessary information since
we consider CSS classes and their names part of the public API). We would now need documentation for our styles declaration and the source code is way too syntax/API heavy.

@mnajdova
Copy link
Member

@mnajdova I'm not entirely sure the solution has to be found on the visual regression runner. Look at this demo: https://deploy-preview-23841--material-ui.netlify.app/components/breadcrumbs/#custom-separator once opened in codesandbox: https://codesandbox.io/s/tk3hz?file=/demo.js. There is likely something to do about it for developers too.

Will be fixed by #23934

@mnajdova
Copy link
Member

CSS injection was fixed by #23934

@@ -8,17 +8,17 @@ import MuiLink from '@material-ui/core/Link';
import { useUserLanguage } from 'docs/src/modules/utils/i18n';

const NextComposed = React.forwardRef(function NextComposed(props, ref) {
const { as, href, ...other } = props;
const { linkAs, href, ...other } = props;
Copy link
Member

Choose a reason for hiding this comment

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

Will we need to update the Next.js and Gatsby examples for the conflict?

test/utils/describeConformanceV5.js Outdated Show resolved Hide resolved
{ muiName: 'MuiTypography' },
)((props) => ({
margin: 0,
...(props.styleProps.variant && props.theme.typography[props.styleProps.variant]),
Copy link
Member

Choose a reason for hiding this comment

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

Awesome.

noWrap: {
const getTextColor = (color, palette) => {
if (color.indexOf('text') === 0) {
return palette.text[color.split('text').pop().toLowerCase()];
Copy link
Member

Choose a reason for hiding this comment

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

In the future, we probably want to change the value supported by the color prop to match the format of https://github.com/mui-org/material-ui/blob/982abc5771c1ce2e0508d9bc79ad0bb9d43743d2/packages/material-ui-system/src/style.js#L5

<Typograpy color="text.secondary" />

Or we could also say, drop the prop for the sx prop instead. It won't be consistent with the color prop of a button but that would be consistent with the other sx usages.

<Typograpy sx={{ color: 'text.secondary' }} />

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good to me, let’s review the color prop on all components and see what patterns are there and make a proposal fo API. Sounds good?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, it will be for a future iteration. It's outside of the scope of this effort.

@DanailH DanailH merged commit 259253d into mui:next Dec 18, 2020
@oliviertassinari oliviertassinari changed the title [Typography] Migrate styles to Emotion [Typography] Migrate styles to emotion Dec 21, 2020
@ghost

This comment has been minimized.

@zannager zannager added the component: Typography The React component. label Jan 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: Typography The React component.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants