Create-react-app: Css available even if not imported

[Jony-Y]

Hi,
I have an issue where once I import a css file the classes are known throughout the app.
e.g:

in LoginContainer I have:
import './login.css';...
<div className="container">//html here</div>
and in ForgotPasswordContainer:
import './forgotPassword.css';...
<div className="container">//html here</div>
both have a different class for container and are imported by different files.
But I keep getting only a single occurrence meaning if I change one container class then html changes for both.

this doesnt allow me to override.
Im used to working with Angular and scss so Im new to the importing css classes so Im not sure if this is how its supposed to work.
But the way it is now for me importing classes doesnt make sense since they are global for the entire project.

as far as changes to the create-react-app boilerplate, I have only introduced the node-sass change
which doesnt effect any of this code since I watch different folders

can anyone assist?

[lucasavila00]

That's css and React's className api. It works like this. There are many ways to work around this.
Check this: https://medium.com/@jdan/rendering-khan-academys-learn-menu-wherever-i-please-4b58d4a9432d#.61i4oesqr

BTW, I use https://github.com/styled-components/styled-components to do the job.

[tbillington]

They are just importing the css file so that when you go to build they all get included, otherwise the compiler/webpack wouldn't know they exist. It has almost no other logic other than adding some vendor prefixes to some css values. You still have to write css in the usual way, it's not magically namespaced at all.

[Jony-Y]

so I dont understand whats the point of importing the css to the js file... why not just have separate css or scss files and have them all compiled to the index.css...
I was under the impression that the css files here are imported and only available for the file they were imported into.

so, to understand correctly, the only way to have specific css for a specific file is to use the style type methods? otherwise including the css just imports it and then once included ALL components are aware of the classes right?

[gaearon]

There is currently no namespacing.

The point of importing is to make the build system aware that this CSS file exists. This way it knows to include it into the final bundle when you compile the code, and to watch for changes to it in development.

[Jony-Y]

@gaearon shame :).
I thought it would work like that and that seemed pretty awesome.

so actually importing in the js files or bundling into index.css file actually makes no difference.
I just found it confusing, when I imported to my containers and saw that:

1. There was no namespacing
2. classes imported in other files can be accessed without importing

[tbillington]

@Jony-Y I don't want to be rude but it might help if you had a better understanding of how css works. There's no way possible right now to do anything like what you're asking with css.

However, there are libraries that link styles to the react component by writing the css in the javascript then it autogenerates custom css names or sets the styles on the html elements themselves so they never clash. Something like this https://github.com/styled-components/styled-components.

[Jony-Y]

@tbillington I understand. I will certainly do my research next time.
I thought it was possible with css modules, I guess I was mistaken.
anyhow I think I got my answer.
My further issues have nothing to do with the boilerplate so Ill close this issue.

thank you for your help

[gaearon]

I thought it would work like that and that seemed pretty awesome.

You might want to check out CSS modules which do exactly that. However they have their own caveats (non standard syntax that some tools don't support).

so actually importing in the js files or bundling into index.css file actually makes no difference.

I don't understand what exactly you mean by this. If you stick to a naming convention (like BEM) and namespace CSS yourself by the component name you are unlikely to have conflicts. The upside of dividing CSS files is that, with some discipline, you know which styles correspond to which components, and where to find them.

It is not a perfect system but it works. And if you don't like it you can always take this CSS and do something else with it.

If we supported CSS modules instead out of the box we would be locking our users into something from which it will be hard to migrate. Do we know for sure CSS modules isn't going to be superseded by another custom syntax in two years? No. Therefore we try to stick with standards for as much as it is reasonable, or at least provide clear migration paths.

I understand your frustration but I think most of the problems can be mitigated by manual namespacing. And if you're okay with using something more experimental then it might be a good idea to eject and add CSS modules.

I hope this helps!

[Jony-Y]

@gaearon First of all let me state that I am very happy with the work that you guys have done with the boilerplate.
And I don't have any problem using the conventional namespacing in my css and scss files (Ive been doing it for quite some time). I just thought that there was a different solution here (I thought CSS modules was implemented here). My mistake for not researching further as @tbillington noted.

I don't understand what exactly you mean by this. If you stick to a naming convention (like BEM) and namespace CSS yourself by the component name you are unlikely to have conflicts. The upside of dividing CSS files is that, with some discipline, you know which styles correspond to which components, and where to find them.

Doesnt really matter, I understood the gist. I know how to proceed.
But it could be nice if the css Modules as I understand them were implemented in the future.... Again I understand the choice of sticking with vanilla.

for now I will use namespaces in my css files to solve conflicts....

Thanks

[gaearon]

I wish there was a better way to solve this.

I'm just not comfortable enabling CSS Modules by default because:

• It uses custom syntax extensions to CSS and breaks some tooling.
• It is local by default and people unfamiliar with this paradigm will file hundreds of issues about CSS "not working".
• This space is rapidly changing and I don't want to embrace a potential dead end solution.

If there is a clear winner in the "local CSS" space that community fully embraces I'd be happy to go with it but it's not the case today.