Distribution CSS

[ojame]

At the moment the build creates a single react-widgets.css file under dist/css - which makes sense. If you want individual component styles, just build the LESS for that component.

However, we use SASS (and hopefully inline in the future) and don't particularly want to add another loader to our build. We also don't use all of the widgets (per application, maybe two or three), so it's a bit of a waste to ship the entire react-widgets.css.

What are your thoughts on having the react-widgets.css stylesheet, but also individual component stylesheets under dist/css as well?

[jquense]

in general i don't mind at all but right now the individual less files aren't actually split up in efficient ways. In general 80% of the stuff is stuck in core.less, b/c the large majority of the css is common to all of the widgets. I want to fix some of that, but the main problem is that LESS doesn't provide a good way of extending styles in a way that would let me isolate them in separate files, without repeating style definitions.

I digress though, Let me see if in the meantime i can just build each less file out by itself. I'm not actually sure I can do that easily but I'll see what I can do

[ethansmith]

I'm in exactly the same camp as ojame, and would LOVE to see this happen. Thanks!

[chrismcv]

Material UI have done it nicely here - there project is now completely CSS free, which is ideal for widgets.

https://github.com/callemall/material-ui/blob/master/src/checkbox.jsx#L35

Would you be open to something like this?

[jquense]

Would you be open to something like this?

I don't think so, I am not a big fan of inline styles. In most cases it solves a problem that isn't there, or isn't already solved sufficiently by a preprocesser at most people's scale, at teh expense of reinventing the wheel.

Practically speaking, in a library like this "maintenance" of styles is pretty trivial. More to the point, inline styles will probably increase byte counts in this case, defeating the point of wanting individual css files in the first place.

[chrismcv]

My concern was so much maintenance of styles in this library, as much as being able to consume this library.

We use webpack, which means that we'd need to have a sass-loader to consume the sass, but even then your css references gif files, so we'd then need to have and image/url-loader to support that, which is much more difficult than the material-ui one.

[jquense]

the problem will be the same even with inline styles, the images, and fonts still need to loaded regardless how you define the styles. In terms of webpack there is no need to use the less files, you can use the built css file. which requires no additional loaders. Plus if you are already using webpack for styles you almost certainly have those loaders already set up. Of course the simplest way to do it is just to add the css file link to the head of your html.

like I said I'm looking into have individual css files built, but honestly I don't think that will be a very big win. 90% of the styles are shared by all widgets so the widget specific styles are very minimal.

I do see how the material up system is convenient and nice in terms of minimizing build steps, but the cost of that is needing to invent yet another theming system. I think that is probably fine for a big ui framework like material ui, but react-widgets is a small suite meant to integrate nicely with a larger app. to that end it seems best to try and use the tools most people are using (css, and a preprocessor) rather than have a small part of the app be very prescriptive about how to style.

[efernandesng]

You can try react-widgets-webpack.
You can select only the less files you need, instead load react-widgets.css