react-css-modules interest?

[chrisblossom]

Is there any interest in integrating react-css-modules into this kit? I can put together a pull request if so.

[oyeanuj]

+1, it looks promising and less restrictive.

[bdefore]

+1

[smirea]

+1

[chrisblossom]

Here is where it stands right now. There are issues with hot-reloading and error handling (probably other things too). I am not sure it is worth the added complexity, although I am sure the current issues can be fixed.

Thoughts?

https://github.com/chrisblossom/react-redux-universal-hot-example/tree/feature/add_react-css-modules

[nickeblewis]

+1

[bdefore]

@chrisblossom Can you explain a bit about your thinking there? I wasn't expecting the changes of adding ExtractTextPlugin and webpack-isomorphic-tools without its development switch on. Also, is browser-sync necessary? Aren't styles hot reloading without it?

[chrisblossom]

@bdefore When I put this into my personal project I thought I had tried it without the ExtractTextPlugin, but I think I must have just been following directions from the module's readme. The changes to webpack-isomorphic-tools (which were partially a temporary hack) and the addition of browser-sync were due to adding ExtractTextPlugin.

Much cleaner and seems to work so far:
https://github.com/chrisblossom/react-redux-universal-hot-example/commits/feature/add_react-css-modules-2

[chrisblossom]

I've been trying it out and it still doesn't gracefully work with hot reloading. Often I have to manually refresh the page if the CSS class wasn't there prior.

[chrisblossom]

The client and server consistently get out of sync, which (now that I am seeing this again) is why I went to using the ExtractTextPlugin as the module suggested.

Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
 (client) 8jk.1.1.$/=10"><div class="wrapper
 (server) 8jk.1.1.$/=10"><div data-reactid=".s6b64
Server-side React render was discarded. Make sure that your initial render does not contain any client-side code.

[kaploink]

Personally I prefer webpack's local styles without the react-css-modules layer.

Main concern is that references to class names go from code (javascript variable) back toward config (custom parsed string).

Which of the problems it solves do you guys find most compelling?

[chrisblossom]

@kaploink I was bothered by having to go against the standard css-naming convention. I personally reverted back to not using this module and having a bit uglier code using {styles['css-naming']}.

If anyone is wanting to use react-css-modules in the future, #693 is the base for getting it to work.

Going to close this for now.

[isaachinman]

Hey, sorry to comment on such an old issue, but I'm wondering if anyone ever successfully got react-css-modules working with this boilerplate? I am at a fork now between Radium and react-css-modules, and prefer the latter, except in its build-setup complexity.

[kaploink]

@isaachinman have you considered using just standard css modules, as implemented by webpack's css loader? It's designed to work with react out of the box, and is already set up in this repo.

Radium vs react-css-modules is interesting; they're at pretty extreme ends of the spectrum. Might want to look at some others between, such as aphrodite or JSS. Here's a great summary of the best current options: https://github.com/oliviertassinari/a-journey-toward-better-style.

Also I think there's recently been a bit of a shift away from css-modules in light of create-react-app deciding to not support them without ejecting. This issue is what led to one of the css modules creators making and using styled components instead (css in js).

Personally I'm using Radium at the moment, as highest priorities for me are pure js object composition (rules out css modules) and small inline chunks of style (rules out aphrodite/jss, etc). Downsides of perf hit for repetition in style tag (~25%) and maybe some issues with SSR seem worth the cleaner component composition ability. Watching closely what happens with MUI styling though, as they have a tonne of expertise in inline styling (currently heading toward JSS).

[isaachinman]

Hey @kaploink. I guess they are rather extreme options. I have used Radium in previous projects and am (mostly) comfortable with its methodology.

My only concern with Radium is pseudo selectors. I have no idea why one would elect to use JavaScript to replicate functionality that is already baked into all browsers. Can you explain what you mean by "repetition in style tag"?

[kaploink]

My only concern with Radium is pseudo selectors. I have no idea why one would elect to use JavaScript to replicate functionality that is already baked into all browsers.

Hey @isaachinman, well the pseudo-selectors are just there to support what people are used to doing with css. Whether pseudo-selectors are the best way to track hover/active/etc state and associate that with certain styles is another question. I see them like many other css features - hacks that are handy for common cases, but not generic/pure enough to scale properly to all scenarios (e.g. :hover affect another element's styles). If it's behaviour/state then I think belongs in js, and styling should be purely to describe actual styles. Similar for media queries. Of course, performance considerations complicate things... Here's example js approach to hover styling (more testable) - boilerplate could be cut down a lot (arrow funcs, es7, maybe HOC): https://facebook.github.io/jest/docs/tutorial-react.html#snapshot-testing

Can you explain what you mean by "repetition in style tag"?

As in "css in js" (aphrodite, jss, etc) store their styles in css classes associated with class tag, so can reuse them across similar elements and avoid styling duplication in the dom; whereas radium and pure inline styles just use the style tag and store all styles against all elements (repeat themselves more, bloating the dom and affecting some performance by ~25% apparently).