Idea: Static version of `free-style`
blakeembrey opened this issue · 6 comments
Originally from #35 (comment), the idea is to enable a static version of free-style for use with build tools that'll minimise to only strings and CSS output.
+1 for this.
My use case for this is writing a ui components library. All of the typestyle-generated classes are static, and all dynamic css is done with react style props, so rendering the typestyle things out to plain css during a build step would be a huge win for me.
@blakeembrey, I was able to do something similar with typestyle using ts-node in an experiment project. I used ts-node to register typescript. Since typestyle has a default instance, I cleared it, required the entry point (which loaded up the typestyle instance) and then wrote out the styles.
https://github.com/notoriousb1t/typestyle-cli
I believe something similar could be done with free-style since typestyle is using free-style under the covers.
So, my idea was that this code would minimise into literal strings (like code replacement). Is that how you both imagine it working too? It's actually pretty straightforward to do and I realised it can be made pretty general to improve all CSS-in-JS tooling size (e.g. also extract out things like auto-prefixers so the build doesn't include them). This means it's mostly tied to bundlers like Webpack and Browserify.
However, on that same note, it's actually pretty easy to expand this tooling. E.g. have Pug.js, Handlebars, etc helpers that generate the class-names and a CSS file in the background for output later.
What would be helpful to me is understanding what you want to achieve and what the context looks like. I'd love to help apply some real solutions here for everyone.
https://github.com/cwmoo740/free-style-example
This is basically what I'm looking for: strip out the constant parts of free-style calls, and output them to a separate css file with the class name set to the display name. Keep any property references to dynamic variables, and keep those at runtime as normal.
@cwmoo740 What do you think the value of keeping dynamic code paths around is? I would have imagined that if you're going to try and make it output CSS - the goal is to go all in with that approach and avoid keeping free-style as a library in the code. In that case, I was thinking I'd emit an error when something can't be transformed into a static class string so you could use whichever non-free-style approach you needed.
I like your idea better. I think there's a strong use case for doing all the dynamic styles with inline style tags, and most frameworks have good support for that.