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

New Typography component #506

Merged
merged 12 commits into from
Oct 27, 2022
Merged

Conversation

vmilan
Copy link
Contributor

@vmilan vmilan commented Oct 25, 2022

Description

Shortcut: #265549

[sc-265549]

Create a Typography component to extend Mui Typography so we can have custom props to avoid having these kinds of variants:

  'body1Italic',
  'body1Strong',
  'body1StrongItalic',
  'body2Italic',
  'body2Strong',
  'body2StrongItalic',
  'captionItalic',
  'captionStrong',
  'captionStrongItalic',
  'overlineDelicate',
  'code1',
  'code1Strong',
  'code2',
  'code2Strong',
  'code3',
  'code3Strong'

Copy link
Contributor

@zbigg zbigg left a comment

Choose a reason for hiding this comment

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

I really like the idea.

I'm missing also .d.ts file, so we can have proper IDE help for using this new component.

};

Typography.propTypes = {
weight: PropTypes.oneOf([400 | 500 | 600]),
Copy link
Contributor

Choose a reason for hiding this comment

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

I would propose to use same vocabulary as design i.e regular, semiBold ...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Absolutely, I'll do it.

const Typography = ({ italic = false, weight, children, ...otherProps }) => {
return (
<MuiTypography {...otherProps}>
<span style={{ fontWeight: weight, fontStyle: italic && 'italic' }}>
Copy link
Contributor

Choose a reason for hiding this comment

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

(i know it's MUI5, so not sure)

Isn't it possible to apply custom style on original element? Like <MuiTypography style={...}/> or <MuiTypography className={ourClass}/>.
I worry that additional dom element is just waste of resources.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, sure... making some changes I left this unneeded span, but I already deleted it. Thank you!

import PropTypes from 'prop-types';
import { Typography as MuiTypography } from '@mui/material';

const Typography = ({ italic = false, weight, children, ...otherProps }) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's typography PR, i expect we would have extended support for our colors, we've just got much more colors that MUI native primary, secondary, textPrimary ...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we have indeed, you're gonna be able to do that, like this:

<Typography color='default.background'> {someText} </Typography>

@@ -0,0 +1,20 @@
import React from 'react';
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know if that folder atoms/Typography is going to include major submodule with several files, but looks like no.
So, i would question if there is reason to implement it in file that name says nothing - index.js looks like "nothing", it's just not searchable, there are hundreds of them in workspace and IMO
I would kindly propose to name it just src/atoms/Typography.js and only split into several files if it grows big and unmaintainable.

TLDR: I find folder with lone index.js inconvenient and premature optimization.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I understand, changed!

Comment on lines -2 to 5
import { Typography } from '@mui/material';
import ColorizeIcon from '@mui/icons-material/Colorize';
import MenuIcon from '@mui/icons-material/Menu';
import AddLocationIcon from '@mui/icons-material/AddLocation';
import WrapperWidgetUI from '.../../../src/widgets/WrapperWidgetUI';
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unused imports

@vmilan vmilan marked this pull request as ready for review October 27, 2022 07:14
@vmilan vmilan requested a review from a team October 27, 2022 07:15
<MuiTypography
{...otherProps}
ref={ref}
style={{ fontWeight: FontWeight[weight], fontStyle: italic && 'italic' }}
Copy link
Contributor

Choose a reason for hiding this comment

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

Please include also style prop from user

In this shape, user is completly unable to overwrite style as we're ignoring /overwriting it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok!

Copy link
Contributor

Choose a reason for hiding this comment

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

Just putting the otherProps at the end would be enough, wouldn't it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Just putting the otherProps

@VictorVelarde
It wouldn't work,

  • ...otherProps at end would overwrite this component style
  • style from ...otherProps at beginning is overwritten in this version

Proper "merging" of properties "touched" by component must be manual, like this:

function Outer({foo, style, className, ...otherProps}) 
{
    return <Inner 
       {...otherProps}
       className={clsx(foo && 'outerRoot', className)} 
       style={{color: 'red', ...style}}
    />
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, now styles overrides are working fine.

Copy link
Contributor

@VictorVelarde VictorVelarde Oct 27, 2022

Choose a reason for hiding this comment

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

Yeah, I know about override behaviour @zbigg ... my point here is Does it make sense to restrict otherProps just to style prop and be explicit about it in the code?

I was assuming here that if someone wants to play with style, beyond defaults, they can provide externally all they require (so no mix, but simple overriding), and allowing us to play with other props. Eg, check Typograghy options in https://mui.com/material-ui/api/typography/ and think about gutterBottom, noWrap or others.

Having said that, I'm not super worried about this, we can move on and adapt as required later, if we see common use-cases

Copy link
Contributor

Choose a reason for hiding this comment

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

I was assuming here that if someone wants to play with style, beyond defaults, they can provide externally all they require

I would assume differently and would expect our "design system" components behave like proper MUI components. In this case, that "user provided style" and "props-based style" are properly merged if they reasonably not collide.

For example with normal Typography, if you say <Typography "color="primary" style={{cursor: "help"}}> it just works and we don't care how typography "implements" color.

Nor, we're required to implement "color" by ourselves if we use "style".

provide externally all they require

That would require user to know that weight: "normal" translates to style={{fontWeight: 500}} and that removes half of usefulness of this component.
(and workarounds for this would add even more api surface, like helper functions, exposing FontWeight mapping ...)

I think that robust APIs should ensure what unrelated features are indeed unrelated (as long as it's possible).

variant='caption'
noWrap
className={classes.textValue}
ref={textRef}
Copy link
Contributor

Choose a reason for hiding this comment

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

why are you adding ref here?

Copy link
Contributor Author

@vmilan vmilan Oct 27, 2022

Choose a reason for hiding this comment

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

Because of this: https://mui.com/material-ui/guides/composition/#caveat-with-refs

Tooltip (and a few other Mui components) needs to pass the ref to its children. I had to add the forwardRef in Typography to do that because is a custom component.

Without this, I was having this warning in the console:
Function components cannot be given refs. Attempts to access this ref will fail. Did you mean to use React.forwardRef()?

description: 'Any theme color, default and custom ones',
control: {
type: 'select',
options: ['primary.dark', 'brand.navyBlue', 'default.main']
Copy link
Contributor

Choose a reason for hiding this comment

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

Where is definition of all those colors available ?

(again, Typography.d.ts would be great)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are coming from the theme directly, you can use any color that we have declared there.

This is just a small example to have in the story, just to know you can change the color via props in the Typography component.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess that should be expressed in the typings

Copy link
Contributor Author

@vmilan vmilan Oct 27, 2022

Choose a reason for hiding this comment

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

color is a common prop to Mui components (it's a system property)... do you want to restrict it to only theme colors?

Right now, from what I've seen, it accepts any string. I mean, whether a primary.main or a #000000, for example.

I think should be enough as it is, but let me know.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, now i see that in MUI5 it's much more robust than in MUI4. In MUI 4, only very few hardcoded colors were accepted ('primary', ...)

Thanks for explanation.

Copy link
Contributor

@Josmorsot Josmorsot left a comment

Choose a reason for hiding this comment

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

Nice work! LGTM 🚀

Copy link
Contributor

@zbigg zbigg left a comment

Choose a reason for hiding this comment

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

LGTM, Apart from all comments (mostly explorative) i like it very much and we should make more components like this.

@vmilan
Copy link
Contributor Author

vmilan commented Oct 27, 2022

LGTM, Apart from all comments (mostly explorative) i like it very much and we should make more components like this.

Thanks so much for the feedback, it really helps me.

@vmilan vmilan merged commit 3f26d2f into feature/design-system Oct 27, 2022
@vmilan vmilan deleted the feature/typography-component branch October 27, 2022 15:50
@shortcut-integration
Copy link

This pull request has been linked to Shortcut Story #265549: CORE - Create a wrapper for the MUI Typography component.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants