Separate styles for easier use in universal apps about react-virtualized HOT 13 CLOSED

Initial testing seems promising but I've hit a snag with regard to CSS modules. Essentially if a project is using CSS modules (eg. the popular erikras/react-redux-universal-hot-example boilerplate) then theme.css is imported with scrambled class names that don't match the static class names defined in react virtualized.

It seems like zippyui/react-date-picker would have this same problem and so I've reached out to them to see if they have any thoughts on the general approach.

from react-virtualized.

I could potentially go the route of using markdalgleish/react-themeable to support either classes or styles and at least give CSS modules users an option.

from react-virtualized.

https://github.com/martinandert/babel-plugin-css-in-js is also a good source of inspiration. I would +1 to ship separate js + css, to give the final user the freedom of choice over what they want to do with the css

from react-virtualized.

Hey Daniele! Thanks for chiming in. :)

The more I think about this the more I want to completely get away from external CSS though. The only reason I didn't opt for inline styles a while ago was that I was afraid they would be too limiting for users wanting to override the default appearance (since inline styles always trump CSS-specified styles, unless users go down the hacky route of using !important)...

@cesarandreu and I were chatting about this this morning and he pointed out the react-native Stylesheet. That gave me the idea to maybe define my presentational styles as a plain JavaScript object and expose them via a static proeprty (eg. VirtualScroll.defaultStyleSheet). Then each component could accept a styleSheet property that defaulted to its own static defaultStyleSheet and users could just supply their own styleSheet property if they wanted to override the default for a component instance.

The reason for exporting the static defaults would be...

• It would enable users to easily create new styles based heavily on the initial defaults.
• It would allow users to override styles for all instances of a given component. (Is this too janky?)

from react-virtualized.

I quite like that idea too sadly opens to auto-prefixing issues. A theme giving component that passes down the theme as context could also be an idea (and would allow global or local customisation).
Radium does a nice work too (quite similarly to how react-native stylesheet work), sadly from my experience css/inline styles in react ecosystem it's a minefield in which you need to accept loads of (bad) compromises, https://github.com/michelebertoli/css-in-js offers a great comparison between each library.

My original thought was that if you ship separate css/js the end user can decide what to do with it (load it with webpack, put it as part of their gulp/grunt build, use it as standalone or what not), while forcing the user to follow a specific path could feel frustrating.

from react-virtualized.

You make a solid point about auto-prefixing. Rats... Thanks for the link to css-in-js. That's a great resource to have bookmarked. :)

Separate CSS/JS is actually what I implemented initially (in PR #49) but when testing with the erikras/react-redux-universal-hot-example boilerplate I realized that CSS modules broke that approach and I needed something a little more flexible.

Edit 1: Looks like postcss/postcss-js might be a sweet solution to adding vendor prefixes to inline styles at runtime.
Edit 2: Unfortunately the use of autoprefix + postcss-js also requires a ton of JSON to work, so it's not a good solution for in-the-browser use.

from react-virtualized.

Okay so I've resolved this issue in PR #49 but I'm not sure how I feel about the added complexity. I'd love to get a second opinion if any of you feel like taking a look. :)

from react-virtualized.

Any by "any of you" I mean @oyeanuj, @frankleng, or @dzannotti :)

from react-virtualized.

I think its great, not sure i understand the thinking behind why stylesheet is state and not props (with default props)

from react-virtualized.

Thanks man.

It's in state because what comes into props gets auto-prefixed before being consumed in the render function.

from react-virtualized.

Which... I also felt a little uncertain about. But it seemed like it would make the components easier to work with. :)

from react-virtualized.

Hi there,

@bvaughn has just requested my opinion on this, see https://github.com/zippyui/react-date-picker/issues/59 so here are my two cents:

For app-specific components, I'm totally in favor of inline styles/css modules & other new/fancy styling solutions. But for reusable components, published with the exact purpose of being used by people in various projects/setups, my opinion is that it's best to use plain-old css for styling (of course, you can/should use autoprefixer and also your css preprocessor of choice). The idea is that when people use your component in their own projects, they should just need to include a css file. This ensures your component makes no assumption about the host setup where it's being used, and guarantees you a very broad adoption.

Using inline styles limits styling options for component users and adds css priority issues which can be easily avoided with a "boring" CSS approach. I tend to favor BEM for reusable components.

My exported css usually has static css class names: eg: react-date-field__input, etc
A step further is to use some auto-generated class names (see webpack-contrib/css-loader#93 issue - solved by babel-plugin-webpack-loaders), but at every build, your classnames are updated, so users cannot hook into those, so use them sparingly, only for things that should not change. Optionally you could use a mix of auto-generated and static class names.

Conclusion: For now, for all widely-distributed components I stick to plain-old css. Boilerplate projects and react examples should never use css-modules for loading packages from node_modules. They should use the simple css loader for loading files from node_modules, and css-loader with css-modules for loading app-specific files.

Hope this helps. It's been my experience in over a year maintaining popular react components.

from react-virtualized.

Thanks for sharing that info Radu.

from react-virtualized.