I am learning React and realized that you can use either real CSS by importing a CSS file, or you can use JS which has CSS-like code using camel cases.
Example for pure CSS: import './AppStyle.css' which contains background-color: black;
Example for JS version: const AppStyle = { backgroundColor: "black" }
Which one is better to use and why? Or maybe they’re both fine?
Writing CSS allows all the benefits of CSS (like selectors, media query).
In inline styles, you write Object-like styles vs. actual CSS.
Code readability is worst in inline style implementation, while managing styles using the CSS is easy to maintain.
The inline styles take more space in DOM because all the styles are defined internally along with the DOM element, while CSS is described separately, creating no issues for the compiler while compiling the file.
There is ups and down with both solutions, you can achieve the same result with both, so it comes down to you want styling solution you prefer
Based on my experience,JSX and CSS are different technologies to solve the styling problem.
Good points of css:
css selectors
styling into css files
Good points of js:
js into styling -> sometimes you want to calculate styles over js https://cssinjs.org/jss-plugin-rule-value-function/?v=v10.0.0-alpha.3#enables-functions-for-dynamic-styles
more approaches to solve one problem -> it has js
Recommendation: Try to use one, it reduce the complexity and documentation to read.
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.
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
This question likely has no single direct answer, but hopefully will lead to some best practices or common patterns to use when adapting an existing styles framework to new web component development.
For my case, I have a component <custom-avatar>, and it's all set up properly with self-contained styles and functionality, everything is just peachy.
In certain use cases, the application display needs to stack avatars, just one slightly overtop one other at a diagonal, and the pattern I'm following is using a simple component <custom-composite-avatar>. All this does is wrap the slotted content in a <div> with the correct styling class, but key aspect is retaining the composability for flexible re-use, like so:
<custom-composite-avatar>
<custom-avatar title="first"></custom-avatar>
<custom-avatar title="second"></custom-avatar>
</custom-composite-avatar>
The tricky bit lies in the styles, which are imported from a monorepo that provides the same BEM-ish CSS and component CSS modules to other flavors of the component library like React, Vue, etc. I have the avatar and composite-avatar styles imported just fine, but forcing the intended overlap display is defined with the hierarchical selector .my-composite-avatar.my-composite-avatar--medium .my-avatar {}
So with .my-composite-avatar class applied to the div wrapper within <custom-composite-avatar> and the .my-avatar class applied to the wrapper within the <custom-avatar> and it's own Shadow DOM, that parent/child CSS selector is no good.
I doubt there is a silver bullet for this, but this seems like it will be a rather common scenario as more people migrate to Web Components while using existing styling systems. What approach makes the most sense to ensure that the composite component remains composable, and adaptation of existing selectors pain-free (or at least easy to communicate to other devs)? can this be solved with ::host or ::slotted, or will these cases require significant re-work?
Thanks for reading, your ideas are appreciated!
I would advice to become good friends with CSS properties
because they trickle down into shadowDOMs following CSS selectors.
CSS Custom Properties(variables)
and getPropertyValue
and setProperty if you want to be brutal and make Custom Elements change the outside world.
example
I have an <SVG-ICON> element taking configuration from attributes OR CSS properties
with my favorite lines of code:
let val = this.getAttribute(attr)
||
getComputedStyle(this)
.getPropertyValue("--svg-icon-" + attr)
.replace(/"/g, "")
.trim();
Allows for your standard attribute configuration:
<svg-icon name="configuration" fill="grey"></svg-icon>
But more powerful (simplified example):
<style>
body {
--svg-icon-fill: "grey";
}
svg-icon[selected] {
--svg-icon-fill: "green";
}
</style>
<svg-icon name="messages" selected></svg-icon>
<svg-icon name="configuration"></svg-icon>
CSS = Custom String Scripting
It doesn't often happen, but sometimes the simplest code makes me very happy.
There is no Styling restriction!
These 2 lines allow any String you want in CSS properties:
.replace(/"/g, "")
.trim();
Example
<style>
[name*="globe"] {
--svg-icon-tile: "rect:0,0,24,24,0,fill='blue'";
--svg-icon-stroke: white;
}
</style>
<svg-icon name="feather-icons-globe"></svg-icon>
The --svg-icon-tile has nothing to do with CSS, it is read (and parsed) by the <SVG-ICON> connectedCallback() code to generate a SVG background/tile for all icons named globe.
The double-quotes aren't required, but without them your IDE will complain about invalid CSS.
Have fun coding... you will pull some hairs when you start with calc() in your CSS properties...
But you can take 'CSS' to another level.
PS.
And monitor the future of ConstructAble StyleSheets aka ConstructIble StyleSheets aka Constructed Sheets aka AdoptedStyleSheets:
https://developers.google.com/web/updates/2019/02/constructable-stylesheets
https://chromestatus.com/feature/5394843094220800
iconmeister
What do you think are good ways to handle styling pseudo selectors with React inline styling? What are the gains and drawbacks?
Say you have a styles.js file for each React component. You style your component with that styles file. But then you want to do a hover effect on a button (or whatever).
One way is to have a global CSS file and handle styling pseudo selectors that way. Here, the class 'label-hover' comes from a global CSS file and styles.label comes from the components style file.
<ControlLabel style={styles.label} className='label-hover'>
Email
</ControlLabel>
Another way is to style the components based on certain conditions (that might be triggered by state or whatever). Here, if hovered state is true, use styles.button and styles.buttonHover otherwise just use styles.button.
<section
style={(hovered !== true) ?
{styles.button} :
{...styles.button, ...styles.buttonHover }>
</section>
Both approaches feels kind of hacky. If anyone has a better approach, I'd love to know. Thanks!
My advice to anyone wanting to do inline styling with React is to use Radium as well.
It supports :hover, :focus and :active pseudo-selectors with minimal effort on your part
import Radium from 'radium'
const style = {
color: '#000000',
':hover': {
color: '#ffffff'
}
};
const MyComponent = () => {
return (
<section style={style}>
</section>
);
};
const MyStyledComponent = Radium(MyComponent);
Update 04/03/2018
This has been getting a few upvotes lately so I feel like I should update it as I've stopped using Radium. I'm not saying Radium isn't still good and great for doing psuedo selectors, just that it's not the only option.
There has been a large number of css-in-js libraries since Radium came out which are worth considering. My current pick of the bunch is emotion, but I encourage you to try a few out and find the one that fits you best.
emotion - 👩🎤 The Next Generation of CSS-in-JS
fela - Universal, Dynamic & High-Performance Styling in JavaScript
styled-jss - Styled Components on top of JSS
react-jss - JSS integration for React
jss - JSS is a CSS authoring tool which uses JavaScript as a host language
rockey - Stressless CSS for components using JS. Write Component Based CSS with functional mixins.
styled-components - Universal, Dynamic & High-Performance Styling in JavaScript
aphrodite - It's inline styles, but they work! Also supports styling via CSS
csx - ϟ A CSS-in-JS solution for functional CSS in functional UI components
styled-jsx - Full CSS support for JSX without compromises
glam - crazy good css in your js
glamor - css in your javascript
glamorous - React component styling solved with an elegant API, small footprint, and great performance (via glamor)
styletron - ⚡️ Universal, high-performance JavaScript styles
radium - Set of tools to manage inline styles on React elements.
aesthetic - Aesthetic is a powerful React library for styling components, whether it be CSS-in-JS using objects, importing stylesheets, or simply referencing external class names.
j2c - CSS in JS library, tiny yet featureful
(Source)
Is there a reason you're not styling the pseudo selectors with your label-hover class like this? Or am I misunderstanding your question?
.label-hover {
color: orange;
opacity: 0.5;
}
.label-hover:hover {
opacity: 1;
}
You can't style pseudo selectors with inline styling (CSS Pseudo-classes with inline styles), and I think using javascript to see if the element is hovered is an unnecessarily complicated and hackish way of doing it.
When a JavaScript library creates a <div>, it typically sets a class on the div so that the user of the library can style it him/herself. It's also common, however, for the JS library to want to set some default styles for the <div>.
The most obvious way for the library to do this would be with inline styles:
<div style="application's default styles" class="please-style-me">
...
</div>
However, this will make the application's default styles trump the user's styles. A workaround is to use nested divs:
<div style="application's default styles">
<div class="please-style-me">
...
</div>
</div>
This works great for many styles like 'font' but fails for others like 'position', where the inner div's style will not override the outer div's.
What is the best practice for creating user-stylable elements with defaults in a JavaScript library? I'd prefer not to require users to include a CSS file of defaults (it's nice to keep your library self-contained).
When a JS library has a default set of styles that should be used, but should also be overridden, the JS library should include a separate stylesheet.
JavaScript should avoid adding styles directly as much as possible, and defer all styling to CSS where it's reasonable.
It's common for sets of styles to be toggled on and off. The way to elegantly handle these situations are with CSS classes.
A case where it may not be reasonable to simply use external stylesheets is animation. CSS animations could certainly be used, but for cross-browser support, asynchronous interpolation is used to animate styles from one value to another.
There isn't !notimportant or !unimportant in CSS. And I haven't run into an accepted best practice. It seems like a CSS file is the defacto standard for styles that should be user modifiable.
But if you want to keep things all in one library, I would take your second example, with your application default styles, then append a CSS class to it and prepend something unique to the class name. Then if the implementor wants to override your styles, the implementor could just use !important to override your user styles.
Adding !important to one or two styles in a CSS file shouldn't be a huge deal, but if you're creating a bunch of inline styles, this may not be the best solution.