I have an issue with styling React Components with semantic Ui for React (http://react.semantic-ui.com/). I know I can modify the Semantic UI's styles Core and I did that however sometime I want to put my own styles into their components.
And I really want to use BEM methodology CSS naming convention while defining class names.
Short example, I have <Menu /> Component and I want to change a background of it, so I will add a class <Menu className="menu-header">, .menu-header class has different background-color property.
And the point is, that I cannot modify it without !important, because semantic UI has higher priority (they are grabbing elements more specific, with few classes not just by one like I want to). All styles are being caught by webpack, and my .menu-header styles are at the bottom of bundle.js - webpack output, lower than semantic UI's. The .menu-header class is being imported directly to my new component which uses <Menu className="menu-header"> example by CSS loader in webpack.
What I can do in this case?
My ideas are that I can modify core of semantic ui, change everything out there, but it doesnt solve my problem. Whenever I will want to modify something again, I would have to use !important - I don't like it.
I realized that react inline js styling has the highest priority and it overrides semantic ui styles, but it is a little more complicated than less which I am using an I am not sure whether it would be a good approach in such a big app as the one I want to develop.
I think the use of !important within semantic-ui should be labeled as a bug. I have ran into similar problems and the easiest way to solve it is using inline styles.
You can probably use something like react css modules to help you with that task.
I don't think this is possible. Someone would need to rewrite semantic ui in BEM.
I personally wouldn't use it unless it was in BEM/SASS, I'd assume there are quite a few others as well.
Related
I'm new to Material UI. When should I use props (in the .jsx script itself) and CSS (separate CSS stylesheet) to style MUI elements? Do I still need to use the CSS stylesheets for MUI elements at all, e.g. use CSS or sx={{}} prop? Or should it be left for non-MUI elements only?
While I understand MUI provides us with the template to make style changes using props, I also understand that we should typically follow a separation of concerns, hence the question.
Thanks a lot!
So you can check this out in their docs below.
https://mui.com/material-ui/customization/how-to-customize/#2-reusable-component
I personally wouldn't use CSS with MUI. You can use either CSS or the sx prop to override styles, however it feels like sx is the preferred method. Using CSS requires targeting the specific classname and nesting your classes which I find is quite a lot of work for what is meant to be one-off customizations.
If you wanted to change specific MUI components, I still wouldn't use CSS as you can just create your own themes with the ThemeProvider.
The idea behind MUI is a CSS-in-JS solution so you're sort of doing away with the concept of the traditional "separation of concerns". If you prefer to set up your projects that way, things like Tailwind or SASS/SCSS are more suited to that.
So in summary, yeah I'd only use CSS with the non-MUI components, sx prop for quick style overrides, and the ThemeProvider for global style changes.
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 use library that used css modules within, and styles come to browser with hash, how could I redefine this styles?
Thank you.
So, the answer on this topic is that paradigm of css modules dictate us behavior that doesn't imply overriding styles in other component, that supposed to be correct component approach to design interface and protect our production code from unexpected bugs. However if we need to enrich our component with styles from another component we can provide this by drilling props and can adjust this accordingly, e.g. we can check which styles come from the props and filter them out of the wrong ones, e.g. from 'position: absolute'.
upd:
and actually great article on that: https://liefery-it-legacy.github.io/blog/2018/06/27/overriding-styles-with-CSS-modules.html
I am working with a freelance client on the side that wants to utilize Angular Material throughout the project. However, they do not like the way that the underline looks in the angular material input. I have tried a variety of approaches to change this, but I haven't found any success yet.
To be honest, I haven't even been able to find the tag in the DOM that would let me alter that border.
Here are the Angular Material docs, as you can see all of the available options have at least some form of a bottom border.
Some approaches I've tried:
This one is from the old angular material and no longer works for the new angular material
The accepted answer here is for the new angular material, but I was not able to get it to work. I implemented exactly as described and no styling changed.
This approach looked like it would work. Unfortunately, I could not get it to work either.
Any help or input on this topic would be appreciated.
For reference, the client said that any changes that deviated from the desired design would be denied. So I have to get this to work. I believe I could maybe, possibly lobby to build a custom input component as a solution, but I know that they are dead set on Angular Material.
Edit. Added a pic of desired look:
this little code did it for me. I didn't want to display it and just set height and width to 0.
::ng-deep .mat-form-field-underline{
height:0 !important;
width:0 !important;
}
However I think its kinda hard to style the Angular Material Components and for me its sometimes better to built my own.
First of all, you'll need a .scss to be imported either within the default theme.scss or after the import of the material stylesheet in main.scss.
Now, Material offers you the option of customising colours and some of the styles by overriding their #mixins found somewhere in the Material folder ( I don't have the folder in front of me.. very sorry for the vague pointing... ).
Back to the newly added file; You can override material's default styling by checking the DOM for certain classes and then adding them in said file with the desired changes. Because the file is loaded after Material's, the default styling in overridden. Same thing applies for the #mixin you chose to override. Just have a look in the file, copy-paste the whole #mixin and change accordingly.
Now if you wish to go even further, my colleagues and I have a custom library that uses Material BUT the whole styling is stripped off leaving you with the bear input within the mat-form-group and then using a <input disabled/> with a position:absolute over it. That way you get to benefit from material without using their style.