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 making a react app with styled-components and I want to create a component that will be just like using col col-x and another for row classes from bootstrap.
But my problem is that I can't find the styles for that, I searched for every .col word in the repo and couldn't find anything.
How can I make a component using styled-components that recreates bootstrap col col-x and row without importing the entire bootstrap?
You should be able to get it from the Bootstrap CDN https://stackpath.bootstrapcdn.com/bootstrap/4.5.0/css/bootstrap.css.
I usually approach this kind of issue by creating a page where I load the library I try to partially emulate and apply it to the structure that I will intend to have. I will extract CSS rules from the dev tools (after loading it in several browsers to find differences of use-cases) and create the same CSS rules into another page, having the same structure, but not using the other library, which is Bootstrap in this case. If there are non-CSS differences, that is, the way that structure is rendered is partially managed by Javascript, then I will make a list of things to achieve and try and find the code for that. In general this will reduce the list of things I have to implement to have only a few items, which tends to be doable.
I have written an embeddable Web component for data visualization. There are of course associated css classes in addition to the js and html. I need to isolate the css classes so they do not override and/or clobber css class names of the larger Web app context it gets embedded in.
What is the best practice for achieving this?
A possible way to fix this problem is to use scoped CSS. I don't prefer the solution and only use it when nothing else is possible.
I just found out that scoping is not supported, at least not all browsers support it, only Firefox does
Another solution would be to use a prefix for all your CSS classes and id's, but this could take a lot of time if your files are large.
By the way, if embedding means in an iframe, there is no problem, because it does not apply the css of the site imbedded in.
I know placing all your styles in a CSS file is the best thing to do as it is a lot neater.
But does it REALLY matter if the styles are inline or in a CSS?????
Edit below
My plan is to just place the styles in my MasterPage and all other pages will use the MasterPage....I believe the correct term is not "INLINE" but Embedded???
Some thoughts from one with experience, rather than a 'purist':
Storing all styles, for a large application, in one CSS file is not maintainable. You'll have perform a text search of the file to find the style you're looking for, or scroll a lot, and there's a higher chance that you'll overlook related styles when making an update.
If certain styles are particular to a page, not globally used, it is more maintainable to keep them in a style tag within the head tag.
Deep CSS inheritance hierarchies are also not maintainable. These are much, much worse than inline styles!
The CSS language itself does a poor job of applying styles to many elements in more complex structures. Consider lesscss, sass, or even jQuery for more than basic application of styles.
Lots of developers use HTML for presentation, mostly DIVs, when they think they are doing the right thing, or lecturing others. Some example above!
Using Inline CSS:
Repeat the same rule for every
element in the page.
More code and bigger file size to
transfer to the client.
Harder to maintain, suppose you want
to change the width to 200px, you
will need to go through all the page
and edit one by one.
inline:
<div style="width:100px; height:100px;"></div>
<div style="width:100px; height:100px;"></div>
external OR put css classes in the head [embedded styling]:
<div class="big"></div>
<div class="big"></div>
Based on your edit: that seems not to be inline CSS as in my example above, it is the same idea as using an external file, so if you want to do that go ahead, it is the same.
It matters because your code becomes very difficult to maintain or update if you use inline styles. Keeping your styles in style tags or separate CSS files allows you to comply with Don't Repeat Yourself, which is probably the most important development principle.
That being said, if you are absolutely certain that a piece of styling is unique to a given element, and also that it won't ever need to be tweaked, you can feel free to use inline styling. I sometimes use inline style for throwaway code and for things like landing pages (once they're done, they're done).
No but it is alot easier to make changes to the css if you only have to look one place instead of all your headers/inline
One other thing, your markup looks alot cleaner if you dont have eny css/javascript inline
When creating master pages I use in-line styles to create the basic layout of the page. For instance I include all of the styles that position the header at the top of the page, main content in the middle and footer at the bottom. Pretty much every style attribute related to positioning, I include in the masterpage as an inline style.
Storing styles in one document helps you to control on your entire project. Furthermore less code to maintain and applying changes.
It is a loth easier for maintenance... does it really matter depends on what you think what is important... why wouldn't you use a css file?
Do you mean putting your styles in the with or attaching them as 'style="x"' to your element?
There's several reasons for avoinding inline CSS.
1) Maintenance, it's easier to make changes to a code where all css is seperated from the markup itself. It also makes the code more readable as avoiding alot of inline css gives you less code.
<div class='test'></div>
is easier on the eye than:
<div style='background:yellow;width:10000px;height:10px;position:absolute;top:10003px;left:132032px;'></div>
When the css is inline you will also have a hard time finding where the code itself is and comparing styles. You will also often end up repeating the same code several times because you can't use classes.
2) Performance, CSS files can be gzipped, making for a smaller load. It's also easier for the browser to handle when it get js and css served as files.
3) Keeping with the best practice. Some other poor developer might want to edit your code later, and he sure would be happy if you kept away from inline CSS.
Now of course you can do CSS in the head of a document too, but why make your files bigger than they need to be? More code into the same file makes for more mess. And you can't gzip it if you do.
#Etienne , there is one disadvantage doing this way , if you want to deploy any changes to production you have make a build and push it.
If you maintain everything as css , you can just push the css file changes and invalidate the load balancer cache.
I thought this is a good point to mention.
When it is best to use inline style
Inline style is the best solution in situations when some style is created dynamically from user input via server-side code (ex, WordPress plugin), to be applied only to a single HTML element, in such cases insert it into an external CSS file causes only problems:
There is the need for a server-side code that creates a CSS class
with the dynamic style inside it.
There is the need for a server-side
code that write and save the .css file
There is the need for a
server-side code that is able to link the CSS classes created to the
correct HTML elements You must load an external CSS file for no
reason, this is a downgrade of performance (file size and 1 more HTTP
request)
In many cases, where the dynamic codes are just one or two,
the problems are startling clears: you must create a file of ex.
800bytes with 2 lines of code, and load it as external files.
Greater exposure to bugs. More a code is complex more are chances of bugs. The server-side codes above are very complex in comparison to the simplicity of the task they do.
Real use-case:
Imagine a scenario where a user wants to upload an image and use it as a background in an HTML element. With old rule is just style="background-image:URL()". with the new rule some code must create and save an external file, with just the code style="background-image:URL()", create a CSS class for it, write it in the HTML component, load this CSS file with just one line of code. Totally nonsense. Consider also that this operation must be done every time the user updates the image.
Final result:
Worst performance due to 1 more HTTP request and large, complex, server-side codes.
Wasting hours of time for authors to develop something that is not only useless but also creates real problems.
At least one more file in the project
Worst readability/comprehensibility of the code because a user must check the HTML and then find the CSS code of the linked CSS class to see the value of the style.
When it is best to use an external CSS file
In all other cases than the ones explained above, in short, when the style is fixed and never change you should put it in an external CSS file.