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.
Related
I am currently implementing a plugin that gets dynamically incrusted into a DIV (not an iframe) and am currently using Bulma as my CSS framework. The issue I am having is that since this plugin is going to be integrated into many sites, it will also inherit the styles applied to the parent website.
Due to many of the classes being a standard name in many frameworks, such as column, button, form, and others, this is creating a conflict.
I have been reviewing a couple of packages that either add a prefix to these classes as well as use a namespace.
Namespace:
The namespace route does not work since this does avoid our plugin from not interfering with any of the other sites' styles, the site's styles still affect ours.
Prefix Packages:
https://www.npmjs.com/package/gulp-class-prefix
The other route I was researching ways to add a prefix to all the classes from our plugin, such as -column, but I understand that this will output a CSS library with all the classes with the prefix but not my HTML files which have the class="column".
I am hoping to find a solution for this, as I would think this is, although not common, a recurring issue/question and I just haven't found the proper solution for this.
Any advice would be appreciated.
You can use the #layer css rule:
The #layer at-rule allows authors to explicitly layer their styles in the cascade, before specificity and order of appearance are considered.
Example:
/* styles.css */
#layer bootstrapFramework, myPluginStyles;
#import url("https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css")
layer(bootstrapFramework);
#import url("https://yourPluginStyles.css")
layer(myPluginStyles);
Doing this will override bootstrap classes with your plugin CSS classes. Due to the order of the layers.
Check out the browsers support for the rule.
You can read more about #layer CSS rule here: https://developer.mozilla.org/en-US/docs/Web/CSS/#layer
You can also checkout Web Dev Simplified Channel by Kyle on youtube. Here is the link to the video: https://youtu.be/Pr1PezCc4FU
Hope this answers your question!
Yeah. That's fine. Just add a prefix to the HTML classes too. It should work.
Or you can choose to ditch CSS frameworks for the plugin and write the CSS for the necessary components. You just do a little reset for your component's HTML elements and you can expect a fairly consistent design across multiple different implementations.
I feel this may be just helpful too. custom HTML elements too.
Best of luck.
just use div-to-select * { all:revert }
then add the code for the div & bulma
Explanation
all: revert gets every thing to normal so it makes all other frameworks class's styles to default
please take a look on https://agilecss.com CSS framework and UI kit, it provides some unique features not available in other frameworks, for example all the common used UI elements without JavaScript.
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.
I'm working on a react component-based web application and am looking for any strategies for avoiding z-index issues.
Traditionally I've always grouped my indexes using shared SCSS variables, but with fully encapsulated js components this is a bit tricky.
There are different ways of doing this depending on how your project is set up. Do you use sass/sass-files in your build step or are you using a css in js solution (styled-components, emotion, etc.) for this?
If you use sass you can still use your shared variables. Just make sure to expose those variables to your component's scss file by importing the file that holds the scss variable declaration.
If you use css-in-js then the library that you're using probably has a solution for exactly this. You can also go for a more or less custom solution like this guy did: https://fatfisz.com/blog/solving-z-index-with-styled-components
If you use vanilla css you can always use css custom properties and add your z-index layers:
:root {
--overlay-layer: 2;
--sidebar-layer: 3;
--modal-layer: 4;
}
these are just a couople of pointers to how one could fix the issue. Wihtout more context it is difficult to have a more specific answer.
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?