How to avoid z-index bugs with react components - css

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.

Related

what is the benefit of using styled components over using css class for the components

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

Minify CSS class names with Angular CLI

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.

How to use 1 file with variables for less and sass

Is there a way to use just one file with variables and use it within a sass and a less CSS-framework?
In my react project I use semantic UI (less) and kendo react (sass). For comfortability reasons, I want to write only one file including variables like colors, paddings, gaps ...
in kendo theming is pretty easy.
I've found a way to use variables / theming within semantic too.
Here is the link
but now I can't get both frameworks working with just a single var file together as one is using sass and one less.
could find any solution online too.
// semantic site.variables
#fontName: 'Lato';
//kendo variables.scss
$niceBgColor: pink;
#width: 10px;//less
$theme1-PEOGCS:#615149;//SASS dark grey
They have different way of declaring variables and you should
completely separate LESS From SASS, for best practice.
It is bad practice to use both on the same project unless you really
have to do so.
SASS and LESS have a slightly different syntax, you would end up
having to maintain each separately.
Good practice would be for example:
Add Main Folder to project name it: SASS
File: main.scss
inside of SASS create Helper Folder name it: Helper
inside of it add these Files:
_mixins.scss,_variables.scss,_placeholder.scss
To make the code easy to maintain and reuse. Same with less(similar)
If there is a way to do what you want I don't recommend doing it, that's IF. Good luck
How many variables do you have?
The potential problems with this will be much bigger than manually maintaining two files with a dozen of variables in each.
Kendo has older, less-based themes, although of inferior quality. Semantic UI has a sass port. Even converting Semantic UI's less files yourself will be better than mixing less and sass.

How can I isolate the css classes of my embeddable Web component

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.

Copying CSS classes

Lets say that youre using Twitter Boostrap and you have their generic boostrap.css and other boostrap associated css files, and you want your own classes to have identical attributes to some of the given boostrap classes. To my understanding, you would not want to directly modify the css bootstrap files, but you would want to extend them by creating a custom.css file.
So without touching the boostrap files. How would I replicate a boostrap class for my own class? Would the only way be to copy and paste from the boostrap.css file. Or is there a way to do
.myownclass {
-- some command to replicate class 'alert alert-error' without repeating the CSS that has already been written
}
You could use a css preprocessor. Other ways already cited by other users are fine but using a css preprocessor is the best way.
Bootstrap is built using LESS, so you can use LESS. Take a look at here: http://bootstrap.lesscss.ru/less.html.
Also SASS can be used. According to me SASS is better. You find a tutorial here: http://www.1stwebdesigner.com/css/build-website-using-twitter-bootstrap-sass-1/
What are CSS preprocessors?
A browser can only understand CSS, as the styling technique for any DOM element being rendered. CSS, as a language has its own feature set, which at times might not be enough to create a clean and reusable chunk of rules. Eg. Not being able to reuse a collection of rules in multiple selectors, unavailability of variables which may lead to ambiguous pieces of data across the stylesheet. To overcome most of these limitations, the concept of a preprocessor was born – offering an advanced way of writing CSS, which extends the basic functionalities. This advanced code is later compiled as normal CSS code using respective compilers (which depends on what preprocessor you are using), which the browser will understand.
Should you use preprocessors?
The decision of adopting preprocessors for your next project, in my opinion, should be made after much analysis and solely depending on your expertise level and most importantly the project requirement and workflow of the team as a whole. Here are some tips that might help you come to a decision:
Not for beginners: If you are a beginner and starting to explore the fantastic world of CSS, I would suggest you get your hands dirty with normal CSS before moving into a framework or preprocessor of any sorts. It’s really important to understand and be able to use the core concepts of any language that you work with, and that’s true for CSS as much as any other programming language.
Are you a team of front end developers? As a team of front end developers, adopting preprocessors will be a great move. But only if somebody on the team really knows how to handle huge CSS files and structure them accordingly. By making use of the powerful features offered by the language, it is important to first structure the whole CSS into reusable chunks and define a strategy for CSS organization. Eg. Are you going with multiple CSS files for typography, forms, layout etc. Are you going for theme-able UI, where you might need to use variables extensively, etc.
Are you willing to cross the barrier? Adopting preprocessors means you are going to be implementing more programming concepts into your CSS coding approach. There will be a lot of concepts that are native to any basic programming language, which you might want to learn and implement, by using a preprocessor. This means, you will definitely need to brush-up your programming skills and might forever change the way you see a CSS code. If you are willing to cross this barrier, and feel ready to embrace the change confidently, this is for you.
In CSS this is not possible. The only way to do it, is to chain the classes in your html tags.
<div class="alert alert-error myownclass"></div>
If you are using less you can do it like this:
.myownclass {
.alert
.alert-error;
}
This will copy the settings from one class to another. The result will be the same as if you copy the contents of the class directly.
If you are using Sass you can do it without copying the class contents. Just reference the classes as shown below. This will not copy the contents, instead it will reference your custom class at the right position in your css code.
.myownclass {
#extend .alert;
#extend .alert-error;
}
Ref: Sass #extend
You would have to use LESS to avoid copy/paste:
.myClass {
.bootstrapClass;
}
Or you could use any of the other CSS preprocessors TBS has been ported to (Sass has one, not sure on the others).
You could give the element two classes - the original Bootstrap class, and then one of your own making. Then you would target it like this:
HTML
<h1 class="original_class myownclass">Hello</h1>
CSS
.original_class.myownclass {
// css code
}
Here's a little jsfiddle illustrating the concept: http://jsfiddle.net/ApEpr/
This does not require the use of a CSS preprocessor - it's just regular old CSS.

Resources