What is the best way to publish this component?

I’m creating this issue to roll together #26, #35 and #38 as a central place for feedback and ideas.

It appears there are several issues relating to the build process and use of JSX, including:

• Unnecessary packages (reactify) are included for the Browserify build process, when you’re using Webpack (#35)
• Use of .js as the script extension means Webpack needs special config to process the JSX (#26)
• Node.js gets a syntax error when you try and do server-side rendering (#38)

The simplest way to side-step these issues is to avoid JSX in this and any other packaged component, however I’d much prefer to just figure out how to solve this problem and have a great build and packaging process that works everywhere and doesn’t have these issues.

In addition, I’ve created a common gulp tasks package (react-component-gulp-tasks) and a react component generator (generator-react-component) with the hopes of solving the problems of how to build and maintain react components for other developers too. It would be great to get some consistency in this space, imo.

To recap, my requirements for the build process / tasks are:

• Hopefully, ability to use JSX
• Efficient development with on the fly regeneration of scripts (currently implemented via Watchify)
• Live-reload of scripts and css for the examples
• Compatibility with Browserify and Webpack build processes
• Support for server-side rendering with Node.js
• Generation of standalone package for Bower (is this actually useful?)
• Easy ability to publish to npm / gh-pages

I would also prefer not to have to rename my javascript files to .jsx files. This is a purely personal preference; I’m willing to be pragmatic but ideally with the right pre-processor setup, you should be able to switch between using JSX or ES6 syntax in a file, and vanilla Javascript, without changing the extension.

I’d really appreciate everyone’s input into how these requirements can be met, hopefully we can achieve all of them.

[floatdrop]

One big problem of packaging React component is how to manage styles:

• Making styles extendable
• Solving CSS specificity problem
• Escaping global scope
• … all other problems from React CSS in JS.

Like @petehunt says, if you satisfied with inline styles - then you don’t have those problems, but you will need to handle all :hover states for yourself. Downside of this - pseudo-elements (like :before and :after) can not be done this way.

There are couple packages to solve this: RCSS, react-style and others (just search for style in awesome-react). Often they injecting your styles in <style> tag and generate own selector for element (with :before). So it get things working.

But writing CSS in JS is not common in our team (because you have no autocomplete and syntax highlighting is bad).

@nmn can you look at react-styled - is this similar to what you want?

[eedrah]

Hi @JedWatson - you mentioned writing up your learnings. Any thoughts not already expressed in this thread?

Also, did a consensus come of the css discussion and/or is there a more appropriate place to talk about that?