Feature request: exported internal styles

[ricokahler]

• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior/Context

As far as I'm aware (and I could be wrong), there is no way to get to the internal styles object of a component. For example, for <Input>s, I'd like to grab the underline class and use it in an external custom component.

Desired Behavior/Proposal

I'd like to propose that the styles object/function become a property on the component class so that it is available externally.

For example:

const styles = theme => {/* ... */};

class Input extends React.Component {
  // ...
}

Input.styles = styles;

Concerns

Exporting the styles of a component technically means that changing the style object is a breaking change. Maybe instead of Input.__styles could be used instead of Input.styles to let devs know it might lead to breaking changes if you didn't want to be strict about it.

Let me know what you guys think. I'd like to use the internal styles over copying and pasting.

Thanks for the great library!

[oliviertassinari]

@ricokahler The styles objects are already exported:
https://github.com/mui-org/material-ui/blob/835286cb57f765fc9ed74f3dd1880a28fea00d06/packages/material-ui/src/Input/Input.js#L42
It's how we are able to generate the list of the properties in the documentation:
https://github.com/mui-org/material-ui/blob/835286cb57f765fc9ed74f3dd1880a28fea00d06/docs/scripts/buildApi.js#L54-L65

use it in an external custom component.

It sounds like a different use case than #11235.

[ricokahler]

@oliviertassinari oh my apologies, import {styles} from 'material-ui/Input/Input'; does in-fact work!

I was mislead from an error with vscode. It was saying:

[js] Module '"/Users/rkahler/workspace/Skipper/node_modules/material-ui/Input/Input"' has no exported member 'styles'.

I fixed the error by defining and exporting the styles object in Input.d.ts typings file.

Should the typings include a definition for styles and/or other exported fields? I'd be willing to add them in a PR but I'm not sure if that's the right decision.

Let me know what you think, else I'm good to close the issue.

Thank you!

[oliviertassinari]

Should the typings include a definition for styles and/or other exported fields?

@ricokahler Yes, I guess. In the long-term, we want to look into #6218.

[zheeeng]

@oliviertassinari

import { styles } from '@material-ui/core/Input'

In TS, import styles reports has no exported member 'styles'.

And console.log this styles, it is undefined.

I'm building custom Input component and reuse some styles.

[artalar]

@oliviertassinari
I need inputs padding, but it (and other styles) does not accept to button element: https://codesandbox.io/s/mo4xqm9n2p
What i doing wrong?

[oliviertassinari]

@artalar The style was moved. You can find it here now: https://github.com/mui-org/material-ui/blob/e167ea5af7f2a71a0ed132d6879cb77892a4b918/packages/material-ui/src/InputBase/InputBase.js#L66

[eps1lon]

What is the use case for having the styles object exported? We don't have any guarantee for the used css properties currently.

Our public API is simply that a component looks a certain way using a certain set of classNames. I would not recommend you use these styles for unrelated components since they might break on any release.

[oliviertassinari]

@eps1lon We are using it for generating the markdown classes API. I'm not aware of any valid use case for importing them. I never had one.

[ricokahler]

i’m no longer importing styles and i can imagine making styles part of the public API being a hassle so feel free to close this issue.

i think my use case was to get the color of the filled text field variant or something like that? doesn’t matter though

[eps1lon]

@ricokahler Always try to include a specific use case. While it's tempting to just look into the source and say what you want it makes it very difficult for us to find a good solution.

If somebody can provide a concrete use case I'm happy to reopen. I'm closing until then since the author has no use for this anymore.