4 ms·

> The uniform API you are talking about is literally just nested CSS styles with emotion. It is possible to modify deep subcomponents style with emotion. It’s C

> The uniform API you are talking about is literally just nested CSS styles with emotion. It is possible to modify deep subcomponents style with emotion. It’s CSS Nothing more. We are not changing CSS alone here. You can do nested CSS styles through Material UI too. But that doesn't make any sense when you have complex components. If you are relying only on CSS styling then you are tightly coupling the implementation with presentation. Say you have a nested button that is an <input type="button"> in one component. So your nested CSS style in another component that includes this button component would be: "> input[type=button]". Now tomorrow, some developer on your team decides to change the implementation to <button> instead as it is more semantic. Then what happens? All places that have your CSS nested style goes out of whack because of this one change. Because you have hardcoded your nesting. You will then have to change all references from "> input[type=button]" to "> button" just to meet the change in the implementation detail. What is the point of CSS-in-JS if you are going to use CSS nested selectors for inner components? You might as well just use CSS modules instead. If you want to do CSS-in-JS do it the right way. Use JS to expose APIs for your components and CSS to style those components by reference. That way your components are truly independent of each other. Right now with Emotion, changing styles for your nested component implies using nested selectors which makes your components tightly coupled. Now let us make it more complex: What if you want to introduce a <div> in between your parent component and the nested <button> component, as a wrapper? Not only do you have to change your JS implementation but also change all nested selectors from "> button" to "> div > button". It is a big mess at this point! With Material UI it doesn't matter what your implementation is. Your component can use an input[type=button] or button or heck a div that behaves like a button using ARIA roles. It can even be nested 10 levels deep. You can even swap it out with links and it won't fail. Because styling is applied through a JS interface rather than CSS nested selectors. The implementation takes care of where to apply the styles. For the person outside he is just changing the style of the inner component without knowing how it is implemented. That is the real beauty of CSS-in-JS. Not knowing implementation detail ahead of time. We are using CSS-in-JS because of limitations of CSS: you can't define custom components in CSS. If you are going to do traditional CSS with nested selectors using CSS-in-JS then you are just doing it wrong! You don't even need CSS-in-JS at this point apart from it being just a convenience. You can just use CSS modules or regular stylesheets.

player2121 6y ago
Please take a look at styled-system and proposed theme specification with variants. This is how you would expose your inner components for custom styling. https://styled-system.com/variants https://styled-system.com/variants you can use it in Chakra or in anything else that supports this spec.
- shripadk 6y ago
  Variants are not the same as having an API to override styles of inner components. You can use variants in Material UI too (which btw is inspired by styled-system and prior art): https://material-ui.com/system/basics/#variants https://material-ui.com/system/basics/#variants Variants are defined by the implementor of the component in question. What I am talking about is overriding styles by the user of the component. One way to do it is through the ThemeProvider. But that does so globally. If I want to override a style for a particular component only in one place (and the nested components within it) then I will have to use CSS nested selectors or a nested ThemeProvider (which is hacky and ends up slowing down the app depending on how it is implemented). Then I am tightly coupling the implementation with the presentation. There is no API as such to change the nested component styles directly. That is the area where I feel Material UI does better. It has standardized how inner components are exposed to the World for styling. That standardization should happen at the library level instead of at application level. So whenever you import the library you know you have that option available to you too.
  - player2121 6y ago
    > What I am talking about is overriding styles by the user of the component. Please take a look at theme spec where variants become part of your theme object. You use theme.js to provide custom variants to components. This is how you would let users to customize your components via well defined expressed API (typed with TS if you want) :-) > One way to do it is through the ThemeProvider. But that does so globally. You can have as many nested ThemeProviders as you want. This is not a hacky way but is the way if for some reason it's not enough for you to have 1 global theme object. Material UI is great for what it does (implements said kind of design) but if material design is not what you want then using this library with its own layers of abstraction is a no go to me.

player2121 6y ago

Please take a look at styled-system and proposed theme specification with variants. This is how you would expose your inner components for custom styling. https://styled-system.com/variants https://styled-system.com/variants you can use it in Chakra or in anything else that supports this spec.

shripadk 6y ago
Variants are not the same as having an API to override styles of inner components. You can use variants in Material UI too (which btw is inspired by styled-system and prior art): https://material-ui.com/system/basics/#variants https://material-ui.com/system/basics/#variants Variants are defined by the implementor of the component in question. What I am talking about is overriding styles by the user of the component. One way to do it is through the ThemeProvider. But that does so globally. If I want to override a style for a particular component only in one place (and the nested components within it) then I will have to use CSS nested selectors or a nested ThemeProvider (which is hacky and ends up slowing down the app depending on how it is implemented). Then I am tightly coupling the implementation with the presentation. There is no API as such to change the nested component styles directly. That is the area where I feel Material UI does better. It has standardized how inner components are exposed to the World for styling. That standardization should happen at the library level instead of at application level. So whenever you import the library you know you have that option available to you too.
- player2121 6y ago
  > What I am talking about is overriding styles by the user of the component. Please take a look at theme spec where variants become part of your theme object. You use theme.js to provide custom variants to components. This is how you would let users to customize your components via well defined expressed API (typed with TS if you want) :-) > One way to do it is through the ThemeProvider. But that does so globally. You can have as many nested ThemeProviders as you want. This is not a hacky way but is the way if for some reason it's not enough for you to have 1 global theme object. Material UI is great for what it does (implements said kind of design) but if material design is not what you want then using this library with its own layers of abstraction is a no go to me.