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.
Related
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.
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
I'm looking for a way to improve performance by minifying my app's CSS class names. This approach is used by large websites and is also described in this article.
Does anybody have an idea on how to do this with Angular CLI v10+ ? Ideally I'd want to add a webpack plugin while keeping the CLI for compilation, or a similar approach with minimal footprint, obviously for production builds only.
You can achieve something using the ViewEncapsulation API. By default it uses Emulated which generate large CSS class names. If you change that in your components to ShadowDom. This will encapsulate the styles and will shift everything to use Shadow DOM. With Shadow DOM the styles won't be leaked outside the components. You have to test it though and check for browsers support because it's not supported everywhere. Also, global styles might not work as you expect.
Edit: I also found this interesting article that explain something similar using Angular.
I have a task to add rtl support to the site by using some kind of a library to modify css which will swap left to right and vice versa and append [dir=rlt] [dir=ltr] to all selectors accordingly.
What I have done so far:
called ng eject
added rtlcss processor as postcss plugin, but it does not fit my requirements. I need it to append [dir=*] to selectors.
tried other plugins but they did not work.
Possible solutions:
make two css files and dynamically load them. (but then you need to add ViewEncapsulation.None to all components) BAD, not so much work, but can break layout
make two css files and run as two different applications. One for rtl, one for ltr. BAD, no resources for that
make rtl by hand. BAD, too much work
forget about rtl processors and make sass mixins. BAD, too much work
make one css file with correct prefixes generated, [dir=ltr] and [dir=rtl] which will result in a doubly sized css but it will eventually work. GOOD but no idea how to do it
create custom library to do this, or fork existing to modify
find working processor
Currently, I am trying to find working processor with no luck.
Are there any ideas on how to accomplish this?
Am gonna try a template which needs to support all devices most of them recommended me to grid framework because using media query by self may cause time but using framework makes fast.Now the thing is i don't about grid and my task is to finish it with foundation framework.! and which is the best way
*)writing media query by own (or)
*)using framework like foundation
and tell me the way and how to use it thanks a lot in advance..!
There are two opposite ways to accomplish your task.
Using a non-semantic CSS grid framework
There are a number of CSS grid frameworks. The most popular of them probably are:
Twitter Bootstrap;
Zurb Foundation;
Blueprint.
The advantage of using any of those is that you can prototype your grid very quickly by applying the non-semantic classes to your HTML elements. They also contain a lot of handy decorative styles.
But this approach is considered faulty by many CSS developers. There are a number of problems:
By using non-semantic classes you mix structure and presentation, which is fine to make the job done quickly but unacceptable for a serious project.
You force your users to download a huge CSS library while you barely use 10% of it on your website (i have to admit that Foundation allows to import different portions of its CSS library separately, and there exits pure grid frameworks like 960gs that don't contain decoration styles at all).
You are limited with the sizes and breakpoints provided by the grid system. There's no elegant way to override them. Most of grid systems provide only two responsive styles: small and large, while you may want more (e. g. phone portrait, phone landscape, tablet portrait, tablet landscape, laptop, desktop).
Using the power of SASS and Compass
SASS turns CSS into kinda programming language. You can use variables, functions, methods, you can include libraries of code and execute them with your parameters. The possibilities are almost endlest. You write your styles in SASS and then complile them into vanilla CSS accepted by all browsers.
Compass is a bunch of things under one name:
a handy tool to compile SASS efficiently;
a huge library of handy SASS styles for all occasions;
an ecosystem of extensions that you can install and use in your projects effortlessly.
There exist a number of SASS grid frameworks. They allow you to span your elements semantically. Instead of adding classess to HTML, e. g.:
<aside id="sidebar-left" class="grid-2-of-6 grid-4-of-12">
...you apply CSS to existing selectors, e. g.:
#sidebar-left { #include float-span(2); }
Another advantage is that you're not limited with the defaults. You can alter the number of columns, their width, the breakpoints. You can even have different grids for different portions of the web page! And the most tasty feature is that you can have different number of columns for different screen widths (instead of just making your columns ridiculously narrow).
In my opinion, the best SASS grid system out there is Singularity responsive grid framework. It is extremely powerful and flexible and at the same time it's very smooth and simple to use (once you study it).
For responsive media queries you can use Breakpoint or it's jet-propelled sidekick Breakpoint Slicer. Building a responsive grid with Singularity and Breakpoint Slicer is a pleasure.
SASS and Compass provide other fantastic advantages. For example, you can structure your code very efficiently. It's not a proper place do describe all the ways with which SASS and Compass make your life better. I'll just say that CSS compared to SASS is like a copybook and abacus compared to a spreadsheet processor. I suggest that you google for SASS to learn more.
The downsides of the SASS approach are:
You'll have to study it. It takes time.
You'll have to keep your styles in SASS. If you want to edit your CSS, you'll have to edit SASS and recompile. That's not much of a hassle and there are ways to automate this or even integrate into the deployment process, but it takes time and effort to adopt them.
Your teammates are obliged to use SASS too because any changes in CSS are overwritten during each compilation.
Once you start using SASS, you'll never want to code vanilla CSS anymore. That's not a true disadvantage actually. But you should be aware that your life as a frontend developer will never be the same!