Better css in js

[kof]

I think this project would benefit from styles written in js. I particular I am an author of jss and this is a shameless self promotion) There is also integration for react. It is used in production and I think its a more performant and feature reach solution for static styles than inline.

[kof]

the javascript app files in any given application will be changing more than the css files, thus breaking cache more often than the separate css file

Its up to you how you do your builds, you can have separate app.js and styles.js files. This has nothing to do with jss.

[JedWatson]

Sorry for leaving this hanging so long @kof and everyone - we've been swamped with deliverables in the last week. (if any senior javascript devs are interested in a job in Sydney, please ping me, seriously!)

To wrap it up and move forward, I feel the best option is to reimplement styles in Elemental with JSS :+1:

@kof, are you still happy to help us get that done? @jossmac and I are good to go.

[kof]

Yep, I will invest time to finalize button component, polish it till it fits all our needs. Then somebody needs to continue applying it to other components and I will help if any questions or problems appear.

[nkbt]

Just a nice thing that might be helpful too https://github.com/postcss/postcss-js (in addition to jss, I guess)

[MMRandy]

Question, we are just starting to build out a large React app, really like Elemental UI and would like to use it now. Given the decision to port from LESS to JSS, would you recommend sticking with LESS until the port is complete? I know it's early, but any idea how long this would take? Thx.

[nkbt]

@MMRandy I would highly recommend to stick to css-modules in your project.

The whole idea of Elemental styling refactor is about removing this binding to LESS. Having styling done via JSS will allow anyone to use any other styling technique.

[MMRandy]

Thx @nkbt. Seems like the gist of this thread was to move towards JSS not css-modules. The problem I see with css-modules is that it wants to 'modularize' every css file based on extensions, which makes it tough to use Elemental's styles as they are, no? We would need to alter file extension or names, and the webpack build process, in order to have the two play nice it would seem. It would appear like the better approach would be to use JSS at the project level as well...unless I'm missing something which is entirely possible :)

[kof]

just @MMRandy wait until we are done with migration

[MMRandy]

Thx @kof...now I'm going to be that guy and ask: any idea idea on timing for this? A week, a month, longer? Sorry, we're just at a critical decision point and want to pick a horse...thx again.

[kof]

from my side, button component should be ready this week, all other components - depends on others, also it depends on issues we are going to solve on the way ... so it might take some weeks or even a month.

[nkbt]

@MMRandy this is a discussion to what use for library, for the end-product css-modules is better choice as for our experience (we used JSS for several months and then migrated everything to css-modules).

I highly recommend to try both for your project on some fairly complex page and make a weighted choice.

[JedWatson]

we used JSS for several months and then migrated everything to css-modules

Just to clarify, @nkbt is talking about his company, not the Elemental team :)

@MMRandy we're hoping to finish the migration within weeks. At the moment @kof is setting up an example of how best to transition individual components, starting with the Button. Once we've got that to work from, we'll hopefully get through the rest pretty quickly. Some problems (probably) need to be solved along the way, including how to handle theming capabilities (at least to the degree we currently support LESS variables) but we'll probably skip over as many other major decisions as we can, to get the transition completed, and then come back to optimising it.

@jossmac is getting married this weekend (congratulations, Joss :grinning:) and will be on holiday for a week, but I know this is high on his list when he gets back, and once we get comfortable migrating the LESS to JSS it's not really a huge amount of work. (famous last words?)

After the migration, the way you'll interact with Elemental's styles (and theme) will be entirely through JavaScript variables and Elemental's Components, which means it's quite agnostic in terms of what you use in your own project.

It really shouldn't make a big impact on your project when we switch, other than removing the LESS build step; just don't depend on any of our classes (i.e. just use the Components) in your own style sheets and you'll be fine.

So if you are happy to go with JSS, I'd say do that, and this change will fit in nicely with your project. But if css-modules or anything else (Radium, etc) work for you then that's OK too, our goal is to provide high quality components and interface building blocks with as few opinions as possible.

[MMRandy]

Thx @JedWatson for the the detailed response. Looking forward to using JSS for both our project and the Elemental lib. At this moment tho, we started our project with css-modules and are now trying to use EUI on new components...and now I can feel the pain points of attempting to do so.

Is it possible to use EUI alongside of a project that is already using css-modules if your webpack loader is namespacing all the css files? This seems to prevent the styles from attaching to the EUI components. @nkbt, how are you setting this up to use Elemental with css-modules? I can open new thread if needed, thx.

[nkbt]

@JedWatson thanks, yes, had to mention that right away. In our company, of course.

[nkbt]

@MMRandy I guess it is better to transfer this discussion to Discord Reactiflux (#elemental channel or private msg)

[markdalgleish]

@kof Genuinely curious here, I think JSS is great—what does this mean for apps that need server rendering? Will JSS inline a style tag for each component? Is there a way for me to extract the CSS for all JSS-based components on the page?

[kof]

I don't have a definitive answer for that, there are some ways, which might be good or bad in different situations. There is no separate project which takes care of this yet, but we need one or at least maybe some demos of how such builds can be done.

Pulling styles out of react components is relatively easy, its props.sheet.toString()

[kof]

I did some refactoring in jss recently, better abstraction over css rules and now in process is rendering abstraction. https://github.com/jsstyles/jss/pull/113

Which means that jss can get a different rendering implementations.

Now I can write a ServerRenderer without jsdom which can render style tags. If anybody is interested ... you are welcome to contribute.

[kof]

This is basically the reason why I am still not on the button component ...

[vdh]

Could I recommend following Bootstrap's approach and shipping with the compiled CSS for a default fallback?

Even when Bootstrap was only available in LESS (like Elemental currently is), before they added SASS support, they always had the compiled CSS fallback to rely on. Even with their new planned PostCSS support, they'll still have the compiled CSS option.

[nkbt]

with https://github.com/istarkov/babel-plugin-webpack-loaders it is possible to transpile less stylesheets to separate css files if necessary.

[vdh]

@nkbt Could you please clear up this ambiguity, in regards to its CSS styles, is Elemental UI an opinionated or unopinionated library? Because this back and forth is really impacting productivity.

• If it's unopinionated, then it should provide some sort of default CSS, and then worry about supporting one or more pre-processor technologies as additional optional features.
• If it's opinionated, either towards LESS, or towards JSS, or whatever build tool people want to see, then make that dependency a real dependency. Stick to those guns and make your build tool of choice a requirement. Otherwise this underlying problem is just going to keep resurfacing as new issues over and over.

[nkbt]

@vdh I am not an author, only contributor. But as far as I know Elemental was used as part of KeystoneJS internally and has been just recently opensourced. So, to be fair, it is opinionated in fact at the moment, but is now being actively developed to become unopinionated asap.

JSS, by the way, was decided to be an option to make it unopinionated

[nikgraf]

Super interesting discussion! This topic was bugging me since months for Belle as well. Over the last couple days I started to experiment with how a future architecture of a good React UI could look like.

This is what I came up with. In the repo you can find explainations + test implementations for multiple ideas: https://github.com/nikgraf/future-react-ui/

I wonder if this also could also be an option for Elemental. /cc @jossmac @JedWatson @nkbt I also tackled the whole theming topic https://github.com/elementalui/elemental/issues/54. I think we should not leave this out from this discussion since these topics quite connected.

btw feedback is very welcome

Basic Ideas

Class based

Component styles should be class based. It's more performant & responsive styling doesn't work with server-side rendering. I myself went down the inline-styles path in the past, but switched back to classes. Your thoughts?

react-themeable

Leverage react-themeable. It's a nice way of providing many styling classes to a single component. I believe establishing this as a convention would benefit the React community due the consistent API over many libs.

Self-contained

Make components self contained (no global UI lib dependencies) so you can import them and avoid importing the whole library e.g.

// import the whole lib and get Toggle
import { Toggle } from 'ui-lib';

// just import toggle without importing the whole library
import Toggle from 'ui-lib/Toggle';

Ship without a theme

Ship without a global theme so people don't have to import the styling code. This might not be relevant to company internal or in general libraries that a opinionated about styling.

Global theming utility

Provide a simple & handy way to apply a global theme for all the imported components.

[kof]

@nikgraf I was also thinking about it, +1 on all what you said.

[kof]

Added a more detailed answer, lets move this conversation to Niks repository. https://github.com/nikgraf/future-react-ui/issues/1

[wmertens]

Can somebody give an elevator-ride-length summary of this issue? It seems very interesting but not sure what the consensus is currently

[kof]

I think the right way to go for a UI lib is to stay CSS implementation agnostic. I think the theme should not be part of the ui library, but an option. Thats why I have created this very rough spec. I know it is too abstract right now. Please send me pull requests to make it better.

Once I have some amount of feedbacks, we can try to implement it here.

[kof]

Here we go, first step towards better components:

https://github.com/elementalui/elemental/pull/150

[SergioCrisostomo]

I thought I could pin the talk @mxstbr gave on Styling React.JS applications and is related to this very interesting thread.

Followup question: any decisions have been taken to move forward on the styling of elemental-ui components?

[mxstbr]

I'm one of the maintainers of ElementalUI (core maintainer of KeystoneJS), and part of the reason we wrote styled-components was that no other styling in JS solution had what we wanted!

We've started rewriting ElementalUI in styled-components over at KeystoneJS, and will push the new version upstream as soon as we have something releasable. (will probably be a few weeks)

[DenisIzmaylov]

@mxstbr What do styled-components have as a key benefits against of jss?

[tomasvarg]

@mxstbr I'm considering using ElementalUI now so obvious question for me is: will the new version with styled-components be interchangeable with what we've got now or will there be some breaking changes?

[chantastic]

Is this discussion still active or is it a place to be closed?