WORK IN PROGRESS: Precompiles CSS-in-JS objects to CSS strings
by kentcdoddsJavaScript
Last 12 weeks · 0 commits
5 of 6 standards met
Kent, I'm trying to figure out a path forward for best-in-class precompilation in combination with dynamic props-based dynamic styles at render time. I.e. how to achieve a best-of-all worlds here. Regarding this tweet: https://twitter.com/kentcdodds/status/903767274749865984 why exactly would the following be a problem to precompile: Is the idea that the reference to is used only at render time when `myStylesmyStylesmyStylessizeIncreasewindowglamorous.divrenderStaticcreateStylescreateStyles` wrapper, while allowing for maximum flexibility without making too many tradeoffs. I know the use case isn't important to you, but I think it is to a lot of people. You have a lot of experience with this, so any additional information you can think of to help this cause would be very valuable. It's also more important now that you can render to a stream on the server. For example, now at the beginning of a request you can get all the stylesheets you will need just by knowing what chunks a given route depends on, and then append those stylesheets at the top of the page before even starting the streaming of what's rendered. Of course you need code-split stylesheets to do that, but let's just assume you do. In that case I'm not sure what happens with prop-based dynamic style functions, which you'll still want, as after all the whole purpose is to have both static precompiled styles + dynamic styles. But I assume you have something cooking for the streaming use-case without precompilation. In conclusion, I think what you've done with glamorous has paved the way for the ALL JS styling future that will serve us best. And if we can come up with some world-class solutions for preserving static stylesheets when the styles are in fact static while of course gaining the full power of JS, we'll have completed the picture here. The static stylesheets is especially important when it comes to code-splitting. If you have a setup that can generate multiple stylesheets for your dynamic imports, ultimately what you're gonna end up with is better cacheability, as the stylesheets will cache independently of both each other and the JS. And obviously that's just one of several benefits. There's a lot of incremental perf benefits by using static stylesheets where possible that in sum make a difference.
Right now the don't do anything to handle manipulation of the values. I think that it would actually be really hard to do this right. Instead I think that it'd be best to just leave it alone (or throw an error... configurable) if we notice potential manipulation. Otherwise we're basically recreating prepack which I don't think we wanna do :) The nice thing is that for many use-cases, completely or basically static objects are really quite common. And by using this plugin (especially if they configure it to throw a compile error if it cannot literlize some code), people are limiting what they're able to do if they want to completely drop the glamor runtime. So I think this is an ok tradeoff. Also, @thejameskyle wrote this cool thing which should make resolving things across module boundaries a bit nicer.
Repository: kentcdodds/css-in-js-precompiler. Description: WORK IN PROGRESS: Precompiles CSS-in-JS objects to CSS strings Stars: 70, Forks: 2. Primary language: JavaScript. Languages: JavaScript (100%). License: MIT. Homepage: https://npmjs.com/package/css-in-js-precompiler Topics: babel, css-in-js, make-alex-happy. Open PRs: 1, open issues: 1. Last activity: 5y ago. Community health: 71%.