[jss-ssr-vendor-prefixer] make it work on server side

[kof]

I think the best way would be to use autoprefixer serverside. Basically a user can do it already now by passing the css generated by jss to autoprefixer, but this requires an additional build step and setup.

Lets create a separate plugin for ssr vendor prefixing to avoid unneeded dependences for people who don't need it.

[typical000]

Maybe, as a solution - create a flag when initialize jss-vendor-prefixer that describes 2 modes:

1. SSR (server-side rendering) - add all prefixes for all supported browsers. It will work like postcss-autoprefixes. But, in this case, we need additional variable on initialization - supported browsers (like in postcss-autoprefixes - object with versions of browsers)
2. CSR (client-side rendering) - works, like now - adds prefixes only for current browser
   And after, in some way, detect if we create styles on server, or on client - and switch true/false this flag

[kof]

A good alternative to autoprefixer, may be not as feature complete - inline-style-prefixer

[kof]

As we support ie10+ we may not need all features of postcss autoprefixer so inline-style-prefixer may be a good alternative cc @rofrischmann

[robinweser]

(y) I will soon implement the Autoprefixer test suite (at least all relevant browser versions), but sadly I spill beer over my Macbook. It's still working, but I will wait for some days to let it dry completely. Feel free to add feature requests or bugs if the prefixer is missing something.

[kof]

We need a platform that buys open source contributors a new notebook once they loose theirs!!!

[robinweser]

Big companies could donate old notebooks :P But as far as I know a lot are already doing so, e.g. to open coding schools for kids, homeless people, etc.

But well, it's still working, so no worries haha :D It even is quite relaxing to have some days forced not to code. I'll ping you on Gitter as soon as I am back^^

[nathanmarks]

@kof

Are you still thinking of using inline-style-prefixer? This issue definitely a feature that material-ui would need to have a good solution for.

[avocadowastaken]

So as i get, there are two solutions for it:

1. On server side build stylesheet for all browsers and rewrite on client side for current browser
2. On server side build for current browser and do same on client side

---

Problem with first approach:
Currently class names get names from stylesheet hash, so if stylesheets would be different on client and server side we will get errors from react based on wrong classnames

Problems with second approach:
Common pattern with jss - is to use singleton, so inline-style-prefixer or autoprefixer plugin will be applied once to singleton, so there should be tool that will allow to render css stylesheets based on user-agent, e.g.: jss.sheets.toString(userAgent)

[nathanmarks]

@umidbekkarimov

Best bet for server side compatibility with changing styles is to use the factory method instead of using jss as a singleton.

I'm developing a quick prototype solution using jss right now for another project, and I've abstracted away all of the jss methods, even createStyleSheet.

[avocadowastaken]

@nathanmarks agree, I'm thinking about rewriting useSheet method from react-jss to work with react context and create JssProvider component to provide custom jss instance.

@kof what are you think about it?

---

Also I have some ideas for attaching jss sheets on server side based on https://github.com/nfl/react-helmet

[kof]

@nathanmarks have you looked into inline-style-prefixer, do you see any issues there?

[nathanmarks]

@kof the main downside is that it's a fairly large lib if you use the dynamic version. For a jss integration, It would be good for users if they could decide whether to use the dynamic or static version.