test two levels deep

[nmn]

sometimes when using both a media query and a pseudo-selector, it may be important to change the styles with the pseudo selector within a media query.

For this, it is important to support styles that are nested more that one level deep.

[chriskjaer]

You're right. Something like:

const palm = '@media screen and (max-width:600px)';

const styles = StyleSheet.create({
  container: {
    color: 'red',
    ':hover': {
      color: 'blue'
    },
    [palm]: {
      ':hover': 'green'
    }
  }
});

[nmn]

Yes. Exactly

[nmn]

Any update on this?? really looking forward to having this last thing fixed.

In the mean time, I've been working on a browserify transform called 'inlinify' (for now at least). It is relatively general, but it is super useful with stilr.

The transform eseentially, takes certain files and inlines there output.

So let's say I have a file called styles.js that looks like this:

var StyleSheet = require('stilr')

module.exports = StyleSheet.create({
  container: {...},
  item: {...}
})

the Inlinify transform transforms that to:

module.exports = {"container":"_3We8gK","item":"_3GQ4pe"}

Therefore, you can get rid of all the extra bytes that come with using Stilr.

You can use a strategy to create a single CSS file in your build step from all the style files, use inlinify to get rid of the tool completely from your client-side code. You can go back to simply including a style tag in you html file.

Inlinify works by taking a simple glob to filter by file name, so it works as long as you keep a consistent naming scheme for all your style files. ( e.g. : style.js or something.styles.js)

I'm working on a second tool that will walk down your dependency tree create a single CSS file from all the style files by requiring them directly. (I'm looking into a way to fold the two things into a single package, but haven't made much progress there yet)

[chriskjaer]

Ahh, yes. I'm actually going to take a look at it right now! :)

That browserify transform sounds really cool. I would love to take a look at that when you have something working! I've been planning on doing something like it for Webpack, but man, webpack really isn't as straight forward to work with as browserify...

[chriskjaer]

Implemented. Closed in 8b3d8b50a58ce4b4fb63aa1331f1dd3bdbf390da

[nmn]

Sorry to bug you here, but the module-inlinify transform is published. It's useful for when using stilr in production. As long as you keep all your style code in separate files with consistent names, you can remove stilr from your js bundle completely, and replace the style files with simple objects that map your keys to the generated classNames.

https://github.com/nmn/module-inlinify

[nmn]

I'm working on some modules more specific to stilr as well. I will do a fork of module-inlinify, that outputs the CSS string to a file path that you define. This would mean, all stilr specific code needs to be in separate files. stilr should never be required in your js files directly.

[chriskjaer]

That's awesome! We have bunch of helper style files were I could see that come in handy.

But, we usually stick with having everything together in one react component. We've found that the colocation benefits of having the styling and presentation together in one small component is really powerfull. I also experienced that it prevents you from building too large components, or rather you notice that you're building a too large and complex component faster, because the Styling is growing with it and so I see myself rethinking and refactoring more often

So having a transformer that could strip out the StylsSheet.create directly from our components would be even better ;)

[nmn]

@chriskjaer I'm actually considering an AST based transformer that rips out StyleSheet.create calls etc. The problems is that it is much harder to support any dynamic behaviour within the styles. By relying on a separate file, I can pretty much allow any dynamic code that you need (synchronous for now)

I think variables and extentions are at least very important while writing CSS.

I'm new to dealing with the AST, but I'll keep looking.

[chriskjaer]

Indeed, variables and extensions are a key part of doing all this in javascript. Without it, we might as well do plain old css. If you find anything interesting, keep me updated!

[nmn]

I did some more research for transforming StyleSheet.create calls within a module itself. It probably possible to compile that part, but it wouldn't remove the require calls to other modules that are only needed for the styles. In theory it should be possible, but I'm not an AST expert that I can actually deal with it. :(

For now I need module boundaries to make this stuff work. Instead I'm working on three other modules that extend inlinify:

• Add an output file path, and the transform will create a CSS file at the path automatically on every browserify bundle.
• Using some existing CSS parsers making it possible to write your CSS in CSS syntax, but using it like it was written with Stilr and javascript. (This would have some downsides because of requires etc.)
• Using the Stylus compiler, to do something similar, while also making it possible to import files etc.