How can I use my own class names when using CSS and Style loaders? I'm using React and i often get confused with all the class names and the related components. If it is not recommended to keep the class names, how can I organize my code in a manner that it don't get messy?
You can use normal classNames and then import the relative .css file that has the style for those classes. Something like this:
MyComponent.js
...
import '/path/to/css/style.css'
...
render() {
return(<div className="MyComponent">Hello</div>);
}
...
style.css
...
.MyComponent {
width: 100px;
background-color: red;
...
}
...
And this would work just fine, with this approach though you are in charge of naming your classes and making sure there are no collisions and everything is named properly (you can then follow BEM techinque or others as you prefer).
Otherwise there are other approaches that I am not gonna explain into details because the relative docs are great and don't need any addition.
You can use Css Modules or Styled Components. There is also this article that has a good overview of these methods and can help you out make a final decision.
Related
I am using react and came across a situation where I needed a fallback CSS property.
Normal CSS code:
.grid{
position:sticky;
position: -webkit-sticky;
}
Currently, I am getting it done by using two different classes and adding both the classes to the component (using classnames library).
Like this:
<Grid className={classnames(c1,c2)}/>
where c1 and c2 both have position property but with different values.
My question being that am I doing it in the right manner? If not, Is there any workaround?
.c1{
position:sticky;
}
.c2{
position:-webkit-sticky;
}
The browser will apply what it suports. I never worked with React, but I'm pretty sure there'd a better way to write the fall-back properties.
I am coming from a CRA background and working my way through Next.js version 9.4.2
My project tree looks something like this :-
pages/
_app.tsx
index.tsx
components/
Navbar/
index.ts
Navbar.tsx
Navbar.scss
Inside my Navbar.tsx I have a statement import './Navbar.scss';
This gives me the following error :-
./src/components/Navbar/Navbar.scss
Global CSS cannot be imported from files other than your Custom <App>. Please move all global CSS imports to src/pages/_app.tsx.
Read more: https://err.sh/next.js/css-global
Location: src/components/Navbar/Navbar.tsx
The error, as mentioned, goes away if I move the import Navbar.scss statement to pages/_app.tsx
I know I can switch to Navbar.module.scss, but I don't want to go down the route of modular scss as I expect my scss to get complex I would like to stick to the manner in which I write my scss and not keep finding work arounds to issues that might arise later. I am open to being convinced here but I have not found good read ups on this to choose it as my path.
So by the looks if it, I am stuck with importing all <component>.scss files in _app.tsx. This will leave me with a long list of <component>.scss imports in my _app.tsx and I will also be left with a lot of <component>.scss files for Components that might conditionally not render.
What are my options here ?
Your Navbar.scss file is not named properly.
Let's say your stylesheet contains something like...
$color: red;
.someclassselector {
color: $color;
}
Component stylesheet files have to be named in the following convention for next.js to compile them as addressed in next's css getting started guide
<TheComponent>.module.scss
be imported like this:
import styles from './<MyComponent>.module.scss>';
and be applied to the component like this:
<TheComponent className={styles.someclassselector} />
Not really an expert but it seems that you should stick to class selectors as global selectors can only be declared if you import them in pages/_app.js. You may name a main.scss file to use Global or Tag Element selectors like h1 {},h2{}, * {}, etc.
Here I want to generate a separate stylesheet for Landing component and hopefully for other. Other components will have Hero component too. Can anyone tell me how can I do that?. Is it a good idea?.
Anything with an underscore _name.scss, tells your sass compiler that it's a partial scss file. Simply don't use an underscore for single component scss files, for example: Hero.scss. Then in your Hero.js, you can import the style like so:
import './Hero.scss';
<div className="heroContainer">...</div>
or, if your webpack has been configured to allow scss module imports, then you could do:
import { heroContainer } from './Hero.scss';
<div className={heroContainer}>...</div>
If you want to share heroContainer's styles with other stylesheets, simply use the #extend in your scss file.
clientsContainer {
#extend .heroContainer;
}
The downside to this approach is that you'll have to manually import any partials, like _vars.scss, _mixins.scss...etc, and any other dependent stylesheets into each new Example.scss file.
Ideally, if you're working in a large team, it's better to individualize your scss stylesheets, so that everything is modular (components and their styles can be passed off to someone else, instead of having to send ALL of your stylesheets for ONE component).
Is there a class name convention used in material ui library? I'm currently using material-ui-next. I notice class names like "MuiFormControl-root-124" all over the place with numbers appended to class name. For Paper element "MuiPaper-root-18 MuiPaper-shadow2-22 MuiPaper-rounded-19". I just can't see a pattern here.
Is there a convention which I'm missing. It would be easier to understand this framework if it made sense like Bootstraps grid classes. All help much appreciated. Thank you.
In material-ui v1, class names are non-deterministically generated at run time, so there is no convention you should adhere to. That's described here in the docs:
You may have noticed that the class names generated by our styling solution are non-deterministic, so you can't rely on them to stay the same.
However, that does not matter because you should never be using raw CSS class names in the first place. Instead, you use withStyles to set the appropriate styles for each component:
import { withStyles } from 'material-ui/styles';
// Define the CSS styles you which to apply to your component
const styles = {
root: {
backgroundColor: 'red',
},
};
class MyComponent extends React.Component {
render () {
// withStyles automatically provides the classes prop, which
// will contain the generated CSS class name that you can match
// to your component
return <div className={this.props.classes.root} />;
}
}
export default withStyles(styles)(MyComponent);
These non-deterministic class names have technical benefits, including improved performance:
Thanks to the non-deterministic nature of our class names, we can implement optimizations for development and production. They are easy to debug in development and as short as possible in production.
You should note that this happens because material-ui takes a fundamentally different approach to styling than a library like Bootstrap. While Bootstrap has a CSS library with defined class names that get applied to each element, material-ui uses CSS in JS to inject styling. This allows CSS to be defined and stored alongside the JavaScript definition of each component.
I have a question,
I am working on a project which is written in react.
Everything is based on component in react so based on my understanding everything including css files should be defined in a related component itself this way if we remove the component from the project every related file will be removed so far so good.
However consider this case:
.size{
font-size:20px;
}
as you can see there are many cases as above which can be used in different components. So we want to put all the css files into the related components then we should either replicate the same css definition in different places or for these kind of scenarios we can have a shared folder out of the components. Is there any rule or guideline how to structure the css files in a react project in the right way?
I'm not sure if there is any established way to organized shared css but let me offer some observations.
If you have an App component that imports an App.css. Any of the components used within this app will have access to the class's set in App.css.
// app.css
.test {
color: red;
}
// app.js
import './app.css';
class App extends Component {
render() {
return (
<App>
<MyComponent />
</App>
);
}
}
// my-component.js
class MyComponent extends Component {
render() {
<div className='test'>
this text is red.
</div>
}
}
If you have a css file imported in MyComponent that has a style that conflicts with the one passed from App then the MyComponent style will replace ALL uses of the style.
To put in short, it doesn't matter where your css lives. Putting css into the same place as components is just way we try to keep things organized but at the end of the day the whole app has access to all css. And from the example we can tell that latter definitions of the style replace earlier definitions.