I've been reading about Angular 2's style encapsulation methods where you can write your styles directly into the component.
This method can use the native shadow dom or an emulated one. What are the performance benefits to using either for component specific styles?
It`s a pity, but there are performance problems with emulated styles encapsulation. The thing is, Angular uses attributes to apply CSS rules. And the use of them is not efficient, especially in the current version of Edge.
Here you can see some benchmarks as a proof.
https://medium.com/#andreygoncharov/edge-hates-you-attributes-d15faf162939
So in 2017 maybe you should avoid using Angular styles encapsulation when developing big projects.
Here you can check the status of the issue.
For emulated there are not performance benefits. It's just style encapsulation that automatically scopes styles to specific components.
emulated
With AoT the style rewriting is done at build time, otherwise it takes quite some time at runtime to analyze and rewrite the styles.
The styles are then added to the <head> element.
native shadow DOM
There are some performance benefits because the browser in some situations can know that some required re-render is local to a component, which could otherwise cause full page re-render. I don't know a concrete example though.
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
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'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.