[system] Introduce visuallyHidden style utility#21413
Conversation
|
@material-ui/system: parsed: +1.32% , gzip: +2.24% Details of bundle changes.Comparing: c4351c6...8807efc Details of page changes
|
packages/material-ui-lab/src/VisuallyHidden/VisuallyHidden.test.js
Outdated
Show resolved
Hide resolved
oliviertassinari
left a comment
There was a problem hiding this comment.
It would be great to replace the existing usage of the styles in the components with this new abstraction:
- https://github.com/mui-org/material-ui/blob/70e7ba426b67bc6e589a18db22ad571e2c30f0c8/packages/material-ui-lab/src/Rating/Rating.js#L74-L85
- https://github.com/mui-org/material-ui/blob/70e7ba426b67bc6e589a18db22ad571e2c30f0c8/docs/src/pages/components/tables/EnhancedTable.tsx#L230-L240
While the component abstraction seems great for the table case, I believe the rating case would require to use the style directly (by-passing the component). What do you think of exposing a component and the underling styles in the public API?
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
…erial-ui into fat/visually-hidden
| >; | ||
| export type TypographyProps = PropsFor<typeof typography>; | ||
|
|
||
| export const visuallyHidden: CSSProperties; |
There was a problem hiding this comment.
It sounds like the same problem than: #20379.
| export const visuallyHidden: CSSProperties; | |
| export const visuallyHidden: CSS.Properties; |
|
We have started a migration guide for v4 to v5 in https://github.com/mui-org/material-ui/blob/next/docs/src/pages/guides/migration-v4/migration-v4.md. (Oops, I have just noticed that the headers are wrong in this new page, to be fixed.) @mnajdova If you could update the markdown to include the |
eps1lon
left a comment
There was a problem hiding this comment.
Other libraries offer this as a component, I guess for simplifying user scenarios.
I would need to see the use cases to be able to tell if this is actually simpler for users. The goal is not to "be simple" but to offer tools that make the correct default obvious: If a component makes it easy to use it standalone for invalid use cases then we failed. If we offer it as a style utility then it's obvious that it should be used in existing components such as Link.
In any case: We can always add a standalone component later instead of continuing the component prop pattern e.g. <Link className={classes.visuallyHidden} /> makes way more sense (and is easier to reason about) than <VisuallyHidden component={Link} />
Breaking changes
srOnlyprop support with a style util:visuallyhiddentovisuallyHidden<Rating classes={{ - visuallyhidden: 'custom-visually-hidden-classname' + visuallyHidden: 'custom-visually-hidden-classname' }} />This PR adds the
visuallyHiddenstyle utility. It adds usages in theRatingcomponent and theEnhancedTableexamples. It also removes thesrOnlyvariant in theTypographyin favor of exporting this utility.Simple docs page is also added under the System section:

Edit @eps1lon: