[inline-css] support for inline styles

[mellyeliu]

Implementation

Adding support for inline styles authoring with a new @stylexjs/inline-css package. This allows you to write styles inline in stylex.props() that are pre-compiled within the props visitor using much of the create logic for static and dynamic styles.

This is something we went back and forth on a few times, but ultimately felt that it's good to provide the optionality. We still recommend (and want to bake in enough friction) for people to use stylex.create namespaces for the majority of usecases for readability/maintainability reasons.

import * as stylex from '@stylexjs/stylex';
import * as css from '@stylex/inline-css';

<div {...stylex.props(
  css.display.flex,
  css.padding._16px,
  css.width['calc(100% - 20cqi)'],
  css.color(color),
)} />

The naming of all the above is up for discussion, as well as what styles we should build into this API. I'm also using Properties type from estree for type checking for a first pass, but there might be something better we can use.

Testing

Style types:

• Static values
• Leading underscores
• Object key syntax
• Dynamic inline styles
• Contextual styles?

Tested within docs page the above +

• Different merges of dynamic, regular, and inline styles
• Named imports

Integration work:

• Make work with valid-styles / some way to add linter validation
• Double check minified keys (maybe should default disable this option) and other babel configs
• Add docs
• Fix types
• Cleanup + refactor
• Rethink package name + standard import alias

[github-actions]

workflow: benchmarks/perf

Comparison of performance test results, measured in operations per second. Larger is better.

benchmarks@0.17.4 compare
node ./compare.js /tmp/tmp.d35VXteKA2 /tmp/tmp.FaAeH5QhnU

Results	Base	Patch	Ratio
babel-plugin: stylex.create
· basic create	532	537	1.01	+
· complex create	66	67	1.02	+
babel-plugin: stylex.createTheme
· basic themes	444	455	1.02	+
· complex themes	34	34	1.00

[github-actions]

workflow: benchmarks/size

Comparison of minified (terser) and compressed (brotli) size results, measured in bytes. Smaller is better.

benchmarks@0.17.4 compare
node ./compare.js /tmp/tmp.lF24QdhFXY /tmp/tmp.t47Cz5ZOFS

Results	Base	Patch	Ratio
@stylexjs/stylex/lib/cjs/stylex.js
· compressed	1,311	1,311	1.00
· minified	4,150	4,150	1.00
@stylexjs/stylex/lib/cjs/inject.js
· compressed	1,793	1,793	1.00
· minified	4,915	4,915	1.00
benchmarks/size/.build/bundle.js
· compressed	496,650	496,650	1.00
· minified	4,847,840	4,847,840	1.00
benchmarks/size/.build/stylex.css
· compressed	99,853	99,853	1.00
· minified	747,541	747,541	1.00

[henryqdineen]

It looks like everything in Properties is optional and the Required utility type can help.

Suggested change

	[Key in keyof Properties<string | number>]: InlineValue<
	[Key in keyof Required<Properties<string | number>>]: InlineValue<

It would be cool if StyleXCSSTypes.js also used csstype or at least the same thing.

[nmn]

Good start, but a few changes are needed.

[nmn]

It should probably not be a recursive proxy and the get() should throw an error similar to the stylex package saying you need to compile this away.

[nmn]

You can probably just throw here directly and not define valueProxy at all.

[nmn]

Also, let's add Flow types to this and auto-generate the TS types from that.

[nmn]

ESM doesn't allow an arbitrary proxy for exports from a package. So maybe we ONLY allow a named or default import here?

I think limiting this to a named import makes the most sense right now.

[nmn]

Suggested change

	import * as css from '@stylexjs/inline-css';
	stylex.props(css.display.flex);
	import {css} from '@stylexjs/inline-css';
	stylex.props(css.display.flex);

[nmn]

It is important that that the style objects created by the inline-css package are hoisted to the module level as a constant and not inlined like this. We already have a utility for doing this somewhere.

[henryqdineen]

I feel like it's rare at this point to see frontend code be published CJS-only. Could this be written in ESM and then use babel at build time to create a CJS version?

I have a similar nitpick about styleq but I see there is an open PR for that. One advantage is that it would make the @stylexjs/stylex rollup bundle slightly smaller.