-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nicer css module generated names #90
Comments
Can you please explain this on an example? We don’t “officially” support advanced features but they indeed may work by accident 😄 . I don’t know enough about CSS modules to understand what you’re saying, but we’d rather not make them easier to use because we want to be sure that everybody has the same setup. Otherwise can’t just release updates that switch to another CSS solution, for example. |
True, very good catch @modernserf! I'm +1 for this change. @gaearon // This is now usable like if it was CSS modules!
:local(.button) {
} We didn't specify how it should generate those classes, so they're quite ugly and unreadable – what @modernserf is suggesting is making them more readable. |
Simply using [local]---[hash:base64:5] is nice solution. This will output classnames like |
I don’t think we want to support this. I would actually like to turn this feature off. The reason is we might want to migrate away from webpack in the future. We’d need to make our CSS files are as vanilla CSS as possible (aside from minor stuff like relative dependency paths). I would accept a PR that forbids extra features if possible. |
(Btw I totally understand the benefits of local scoping. We just don’t think it’s a good default for people learning React, and it’s way too custom syntax that is incompatible with many other tools. We’d rather move into direction of encouraging CSS in JS for better encapsulation.) |
I think it's not possible to turn off local scope by default (ref webpack-contrib/css-loader#193), but we can simply set the generated name to whatever the name is anyway. Give me 5 minutes to try that. |
I regret bringing this to your attention. |
@modernserf I understand your frustration but it’s still better than if we change the bundler in a few months and all your styles would break. Having to back out of infrastructure changes (e.g. super fast new bundler) because people relied on webpack in ways like this would be super sad. |
I kind of agree with @modernserf though, this is a nice escape hatch for people to explicitly use CSS modules without needing to eject. It's not like we document or encourage this anywhere… |
People will use it whether we document it or not, and then “create-react-app broke my app” will become the next javascript f*****e. |
A semver-compatible patch update can literally break people’s builds because of it. |
I still haven't found a way to disable it properly, it'll break peoples builds either way. |
We can add a custom loader that throws on non-standard syntax. |
Submitted #97 not in the hope of it getting merged but to have some code to talk about Why would we not add that option to |
@modernserf you could try https://github.com/insin/nwb, it's a similar solution which runs out of the box but also has many additional config options if you need them. |
I would think we'd want to/be able to support css-modules in any future version of this tool even if we move away from webpack in the future. |
I’m not opposed to CSS modules in the future. I only think we need to let this tool live for a while with simple defaults (vanilla CSS is as unopinionated as we can be). When we are ready to focus on figuring the best way to do styling in React apps (both externally and internally), we can revisit this decision. However I wouldn’t want the users’ apps to use inconsistent notations in |
Yeah, according a twitter poll I ran yesterday (130 RTs, 1600 respondents!) CSS Modules is almost as popular as plain CSS (inc. Sass/Less/…) and way more popular than inline styles and CSS-in-JS combined. (this is biased because it's my twitter followers, but 1600 respondents…) That doesn't mean we should be implementing them, but it does mean that any new bundler that doesn't support them is going to have a hard time getting any traction at the moment. That might mean it's fine to leave them in, especially in combination with our "You never need to update EDIT:
Fair enough. |
Maybe... I think the problem css modules solve is going to come up pretty quickly for users, but I do agree that css-modules don't seem hugely mature right now. FWIW I much prefer the idea of something like |
Agree that this seems better if we want to allow it. |
Just chiming in here. I definitely agree the The developer API for this stuff has never been great, but I've now dug myself out a few weeks to work on it so I'm looking at improving it now. That discussion probably should take place elsewhere though. ❤️❤️❤️ to this project, just quietly. |
@gaearon What do you mean with "inconsistent notations in .css files"? My .css files using CSS Modules are 100% vanilla CSS, the magic is done on the fly by webpack and not in the .css. Same thing as referencing an image with If you were to go away from using CSS Modules, it's not much that needs to change:
would change into
This is already dependent on custom behaviour of I think CSS Modules are a much better way of handling css in React than the suggested way of manually namespacing your classes, especially for a newbie not realising that an imported css will be global to all components. |
By “inconsistent notation” I mean extensions like |
Oh yes, agree about those. Never used them. |
I'd like to use CSS Modules... just saying... |
@gaearon why do you want to migrate away from webpack in the future? What tool would help bundling code? |
Is https://github.com/rtsao/csjs moving in that direction? Do you think is an alternative to use nowadays in CRA? |
By the way this whole topic lead me to write a pure JS version of CSS Modules (kinda) called Styled Components. I'm now using it with CRA in my own projects and it's ace. 👌 |
Personally I don't know enough about css modules to know if they are good or bad thing--but I do know that some third party libraries one might like to use, such as react-toolbox, require it to be enabled. Thankfully there is the option to eject, but it would be nice if one could configure some sort of webpack config transform to allow replacing parts of the webpack config without fully ejecting perhaps these transforms could be plugins to allow one to enable things like sass or less if they want. |
I'm fairly new to React, and just learned about CSS Modules a few days ago, so I can't speak with great confidence, but it seems like CSS Modules is just obviously better than everything that has come before (much like React in the domain of UI frameworks). I've been working on my first React app over the last week, a process made easier by the existence of create-react-app, but the inability to start using CSS Modules means I must now pause and learn how to operate Webpack and Babel myself so that I will no longer have to rely on CRA. I was hoping to put that off longer, and could have, if not for the lack of CSS Modules support. I agree that automatically scoping plain CSS would be an unpleasant and confusing surprise to beginners, but if there's any way to avoid that while still making it accessible to those who want to opt-in (perhaps by using a different file extension like .csm), then I think it should be pursued. |
@odigity look at https://styled-components.com/ instead, thank me later ;) |
@geelen @oscar-b just checked out styled-components really cool. 👍 |
@oscar-b It's on my short-list of study topics for the next two days. |
Last 3 years we've developed a lot of large projects for commercial and Enterprise segments using React. We've tried everything including LESS, Stylus, CSS modules, styled-components, SASS and we found that JSS have the best DX ever. With using react-jss by Dan. With CSS you can control your styles by CSS class only while in JSS you can control every property, every value to reduce unused CSS as well as it possible. But there is only one problem in JSS - is learning curve. It may be hard to switch from CSS notation to JSS in a few days or even couple weeks. To solve this problem we've made PreJSS - universal CSS to CSS-in-JS adapter which is actually became platform and ecosystem like webpack or babel. PreJSS have a three basic concepts PreJSS Styles Declarations, CSS Parser, PreJSS adapter.
That's how PreJSS makes CSS world simpler: |
@DenisIzmaylov Since styled-components was your inspiration for PreJSS why didn't you make improvements to styled-components instead of creating yet another CSS plugin to style your components? |
@gaearon @Timer However now v1.0.0 is out and using webpack 2.0 (e.g. not likely to change soon). I suggest revisiting CSS Modules. My current config supports both
This allows both, its an extra only people who choose to use get, doesn't interfere with loading CSS from libs, with webpack2 now in place I don't think CSS Module support is going to die any time soon, and of course CSS Modules rocks according to stateofjs with 97% satisfaction. Thoughts? |
Can you file a new issue about this? Let’s say I’m open to supporting it with an explicit filename suffix. |
@ro-savage thanks for your input, this sounds good, I'll try your config. |
my 2 cents: to me the biggest thing is having cacheable traditional stylesheets and avoiding the render/runtime overhead of calculating styles in every render (which you need to do on both the client and server if doing SSR--not good). I avoid true css-in-js solutions for this precise reason. So a solution that could be great for CRA--and one it doesn't need to implement itself--is a loader that removes css-in-js and converts it to stylesheets. That can be done far down the line in webpack land, long after you have ejected. Someone just needs to make this. That way during development CRA doesn't need to support anything new. And that way developers can have the option to achieve optimum performance if they ever want it. Static css-in-js--the new hotness lol
|
You may not even realize this, but your current config supports css modules, it just doesn't use them by default -- i.e. you can use
:local
in CSS files and it will generate class names, it just doesn't make all class selectors local by default.I'm totally fine with global being the default scope for now (much less confusing for beginners) and adding the
:local
pseudo-class where I need it, but it would be nice if more human-readable classes were generated. Use something like:style!css?localIdentName=[path][name]---[local]---[hash:base64:5]!postcss
as the loader config in webpack.
The text was updated successfully, but these errors were encountered: