I'm new in React and a new dev in general;
I know that there are many ways to style elements in React itself:
importing CSS,
locally scoped CSS modules,
CSS-in-JS via Styled
Components or Emotion,
utility-first CSS like Tailwind statically
extracted CSS with libraries like "Compiled" and "Linaria",
inline styling
style object variable
and two current APIs to style MUI elements:
Styled and
SX
When it comes to customizing MUI components, it's obvious that it's best to use one of these two; it also seems that using MUI doesn't restrict the use of all non-MUI ways to style things.
So I guess I'm asking about the "best practice", or at least "an ok practice" of minimizing the amount of styling techniques used (so that the code doesn't become bloated).
This, in turn, raises questions that are not answered obviously in the docs:
what's the difference between MUI's styled API and the "styled components" (CSS in JS via emotion that we're talking about) ?
Are there absolutely no conflicts between any of React's styling techniques and MUI APIs ?
are there styling techniques that are conflicting with MUI styling APIs ?
if non-MUI elements shouldn't be styled with MUI APIs, is it then considered a best practice to just style with your one favorite way but stick to this minimum ?
whatever way is best, are there cases when it can't be used solely ?
Example: I need to deal with a non-MUI component: to put it simply, I'm trying to center an SVG which may be either too wide or too thin for the screen and this will change dynamically. All I need is for it to be either 100% height if it's tall or 100% width if it's wide; in such way so that scroll-bars never appear.
As reddit answer says: there turns out to be no conflicts between React's and MUI's ways of styling. You just have to ensure your style’s specificity order is how you want it to be. In large codebases it’s always good to stick to one type of styling, even with MUI. It’s very likely you will need to have some styling for non-MUI components. You could use MUI’s styled(), or css in js or SASS or LESS. There is no one perfect answer - readability, maintainability and performance are your main considerations.
So since MUI's styled() should work for all non-MUI components/elements, I would go with that.
Related
I'm new to Material UI. When should I use props (in the .jsx script itself) and CSS (separate CSS stylesheet) to style MUI elements? Do I still need to use the CSS stylesheets for MUI elements at all, e.g. use CSS or sx={{}} prop? Or should it be left for non-MUI elements only?
While I understand MUI provides us with the template to make style changes using props, I also understand that we should typically follow a separation of concerns, hence the question.
Thanks a lot!
So you can check this out in their docs below.
https://mui.com/material-ui/customization/how-to-customize/#2-reusable-component
I personally wouldn't use CSS with MUI. You can use either CSS or the sx prop to override styles, however it feels like sx is the preferred method. Using CSS requires targeting the specific classname and nesting your classes which I find is quite a lot of work for what is meant to be one-off customizations.
If you wanted to change specific MUI components, I still wouldn't use CSS as you can just create your own themes with the ThemeProvider.
The idea behind MUI is a CSS-in-JS solution so you're sort of doing away with the concept of the traditional "separation of concerns". If you prefer to set up your projects that way, things like Tailwind or SASS/SCSS are more suited to that.
So in summary, yeah I'd only use CSS with the non-MUI components, sx prop for quick style overrides, and the ThemeProvider for global style changes.
We write css when we use styled components, and I dont understand the benefit of using it why we just dont use the css we write as a classname for the components. In styled components we have wrappers of the components and when we use plain css we have class names. what is the advantage of wrapping components with styled components
The reason styled components is pushed in React web development is to encapsulate styles to only those components. There is no risk of bleeding css into other components. Rather than learn a new css organisation structure new developers can onboard more quickly.
That being said, it is restrictive, slower to develop with, and adds some page weight by applying same styles you could have shared.
I have found the fastest way to work is create static html webpages with pure css, and organise it in a way you are going to import it into your framework. Then you can have boilerplate html designs that can be tested independently of the compiler, which is so much faster to test in Internet Explorer, Firefox, chrome, mobile devices and all the varying screen sizes.
If you want to use styled components, you can either use this npm plugin to convert your static css into variables to use with style components -
https://www.npmjs.com/package/#inspiraller/create-css-vars
or just don't. Nextjs does not support css imports unless its global, so webpack compiling option is a more universal solution.
Main benefits of styled-components are listed in the Motivations page on their website.
styled-components is the result of wondering how we could enhance CSS for styling React component systems. By focusing on a single use case we managed to optimize the experience for developers as well as the output for end users.
Apart from the improved experience for developers, styled-components provides:
Automatic critical CSS: styled-components keeps track of which components are rendered on a page and injects their styles and nothing else, fully automatically. Combined with code splitting, this means your users load the least amount of code necessary.
No class name bugs: styled-components generates unique class names for your styles. You never have to worry about duplication, overlap or misspellings.
Easier deletion of CSS: it can be hard to know whether a class name is used somewhere in your codebase. styled-components makes it obvious, as every bit of styling is tied to a specific component. If the component is unused (which tooling can detect) and gets deleted, all its styles get deleted with it.
Simple dynamic styling: adapting the styling of a component based on its props or a global theme is simple and intuitive without having to manually manage dozens of classes.
Painless maintenance: you never have to hunt across different files to find the styling affecting your component, so maintenance is a piece of cake no matter how big your codebase is.
Automatic vendor prefixing: write your CSS to the current standard and let styled-components handle the rest.
With styled components it's possible to "enhance" CSS classes with JavaScript code because are written in JS.
const Input = styled.input`
color: ${props => props.hasError ? 'red' : 'black'};
`;
Opposed to writing 2 separate CSS classes and control which to show with JS.
.text {
color: black;
}
.text--danger {
color: red;
}
<input className={`text ${hasError ? 'text--danger' : ''}`} />
On the long run it can produce more maintainable code, but it's a matter of personal opinion if it's better to use it or not.
With styled components you can add logic programming
Our team is just starting to figure out how to create a design system on top of MUI and we are trying to figure out what's the best approach to working with styles.
Up to now, we understand that using CSS inline or CSS module the final styles will be on a separated chunk when we build the project.
Otherwise, when we use CSS in JS approach (Styled components or emotion) you don't have any CSS chunk when you build the project, because styles are on the JS chunks (making them a bit bigger) and then the final CSS is made in the browser side (theoretically hurting the performance).
I tried to check on MUI repository how you are handling styles in your project in order to follow the same approach and that way not mix different approaches, but I didn't understand your strategy. I saw some emotion dependencies, but I couldn't recognize some emotion regular sintaxis on the components. Can you explain to us a little bit how you are doing that?
And finally what way to handle styles do you think has less impact on performance when you create a design system on top of MUI? (following your same approach, using inline styles, styled components, emotion, or another one)
PD: this question is not regarding design tokens, just finding a way to handle the styles that don't affect the performance of the consumers of our design system.
Does inline styling effects a react app load time (FCP, LCP)?
How does it differ from styling in a css file?
Inline styling shouldn't affect react app load time. Furthermore, if there is a chance it affects it, it should lower the time of app render. Anyway, its not recommended to do inline styling, as it makes ur code messy. There are certain cases that u can use inline styling with one rule, but generally its much better to use classes defined in css file
When it comes to inline style within a React component we know it basically is JSX that we are talking about and styling that happens in inline is basically passing an Object to the style prop. Internally ReactDOM takes care of all this.
And DOM styling is managed hence forth. It does differ from loading from CSS file in the same way that you can style in Javascript using imperative approach.
Now coming to the question whether it impacts load speed and you have used (FCP,LCP) in the Bracket.Actually LCP is actually considered only for few elements.
Learn more from https://web.dev/lcp/
Overall I believe, it depends how many style properties are used
inline. And still I believe, It actually increases the load time and
does not decrease it in case of React (because Javascript is involved
not direct CSS file [hence additional work]) for ReactDOM.
I use library that used css modules within, and styles come to browser with hash, how could I redefine this styles?
Thank you.
So, the answer on this topic is that paradigm of css modules dictate us behavior that doesn't imply overriding styles in other component, that supposed to be correct component approach to design interface and protect our production code from unexpected bugs. However if we need to enrich our component with styles from another component we can provide this by drilling props and can adjust this accordingly, e.g. we can check which styles come from the props and filter them out of the wrong ones, e.g. from 'position: absolute'.
upd:
and actually great article on that: https://liefery-it-legacy.github.io/blog/2018/06/27/overriding-styles-with-CSS-modules.html