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
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.
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.
What is the best way to apply some CSS styling on third party Angular components, for example ones of Material or ngx-datatable? I can think of 2 ways already:
Override specific 3rd party component's CSS classes. Disadvantage I can think of is styling might break once we upgrade component to a newer version, as we stick to inner implementation (class names, etc).
Cloning whole code base of 3rd party component and updating CSS directly on that. Might be quite an amount of source code to maintain, and will need some merging if we decide to upgrade the version.
Any thoughts why one is better and what consequences it can lead to are appreciated.
You can override the css in your styles.css file, not in the css file of the librairy. Add the css selector on your file, and start adding your style here, maybe with an !important mark to trully override style.
This way you don't have to worry about future updates of the lib
Forking for little styling purposes is not an option ! This is very hard to maintain
Forking the lib only to override style code is not an option, you have to override the css on your styles.css file !
Reading through documentation for ViewEncapsulation, I'm not finding info that there is a nice way to apply styles for a component, and all of that component's child components. I'm a bit bewildered, as this seems like it would be a commonly employed technique, but the three options for ViewEncapsulation, Emulated, Native, None, don't appear to provide this feature.
My only options, as far as I can tell, are to either place the rules in the global styles (doesn't seem right, as I should be able keep my styles together with the component they pertain to), or repeat the rules within the component and each child component, which is a mess for maintainability.
Is this a missing feature, or am I missing something here?