-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
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 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]), |
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 would propose to use same vocabulary as design i.e regular
, semiBold
...
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.
Absolutely, I'll do it.
const Typography = ({ italic = false, weight, children, ...otherProps }) => { | ||
return ( | ||
<MuiTypography {...otherProps}> | ||
<span style={{ fontWeight: weight, fontStyle: italic && 'italic' }}> |
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 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.
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, 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 }) => { |
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 know it's typography PR, i expect we would have extended support for our color
s, we've just got much more colors that MUI native primary
, secondary
, textPrimary
...
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, 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'; |
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 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.
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.
Ok, I understand, changed!
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'; |
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.
Unused imports
<MuiTypography | ||
{...otherProps} | ||
ref={ref} | ||
style={{ fontWeight: FontWeight[weight], fontStyle: italic && 'italic' }} |
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.
Please include also style
prop from user
In this shape, user is completly unable to overwrite style
as we're ignoring /overwriting it.
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.
ok!
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.
Just putting the otherProps at the end would be enough, wouldn't it?
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.
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}}
/>
}
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.
Done, now styles overrides are working fine.
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.
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
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 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} |
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.
why are you adding ref here?
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.
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'] |
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.
Where is definition of all those colors available ?
(again, Typography.d.ts would be great)
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.
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.
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 guess that should be expressed in the typings
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.
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.
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.
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.
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.
Nice work! LGTM 🚀
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.
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. |
This pull request has been linked to Shortcut Story #265549: CORE - Create a wrapper for the MUI Typography component. |
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: