Conversation
workflow: benchmarks/perfComparison of performance test results, measured in operations per second. Larger is better.
|
workflow: benchmarks/sizeComparison of minified (terser) and compressed (brotli) size results, measured in bytes. Smaller is better.
|
52d003a to
4d0f089
Compare
| } & ((value: V) => StyleXStyles); | ||
|
|
||
| type InlineCSS = { | ||
| [Key in keyof Properties<string | number>]: InlineValue< |
There was a problem hiding this comment.
It looks like everything in Properties is optional and the Required utility type can help.
| [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
left a comment
There was a problem hiding this comment.
Good start, but a few changes are needed.
| const valueProxy = (_propName) => | ||
| new Proxy(function () {}, { | ||
| get() { | ||
| return valueProxy(''); | ||
| }, | ||
| apply() { | ||
| return undefined; | ||
| }, | ||
| }); |
There was a problem hiding this comment.
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.
| if (typeof prop === 'string') { | ||
| return valueProxy(prop); | ||
| } | ||
| return undefined; |
There was a problem hiding this comment.
You can probably just throw here directly and not define valueProxy at all.
There was a problem hiding this comment.
Also, let's add Flow types to this and auto-generate the TS types from that.
| if (specifier.type === 'ImportNamespaceSpecifier') { | ||
| state.inlineCSSImports.set(specifier.local.name, '*'); | ||
| } else if (specifier.type === 'ImportDefaultSpecifier') { | ||
| state.inlineCSSImports.set(specifier.local.name, '*'); |
There was a problem hiding this comment.
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.
| import * as css from '@stylexjs/inline-css'; | ||
| stylex.props(css.display.flex); |
There was a problem hiding this comment.
| import * as css from '@stylexjs/inline-css'; | |
| stylex.props(css.display.flex); | |
| import {css} from '@stylexjs/inline-css'; | |
| stylex.props(css.display.flex); |
packages/@stylexjs/babel-plugin/__tests__/transform-stylex-props-test.js
Outdated
Show resolved
Hide resolved
| module.exports = inlineCSS; | ||
| module.exports.default = inlineCSS; |
There was a problem hiding this comment.
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.
- Rename package from inline-css to utility-styles - Update package.json, README, types, and source files - Update stylex package dependency and re-export
4d0f089 to
fc6cd07
Compare
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| expect(output).toContain('.x78zum5{display:flex}'); | ||
| expect(output).toContain('.x14rh7hd{color:var(--x-color)}'); | ||
| expect(output).toContain('--x-color'); | ||
| expect(output).toContain('_v != null ? "x14rh7hd" : _v'); |
There was a problem hiding this comment.
Can we stick to snapshot tests here? You can keep these checks in addition if you want to, but I think this is a bad pattern than LLMs generate.
| k1xSpc: "x78zum5", | ||
| $$css: true | ||
| }; | ||
| stylex.props(_temp, styles.opacity(0.5));" |
There was a problem hiding this comment.
Can you add a few more tests with this kind of pattern. I want to see what happens to inline styles when applied conditionally but stylex.props cannot be pre-compiled more.
Also, to validate the hoisting logic, can you make add some examples where the stylex.props() exists inside of a function and not the top level.
packages/@stylexjs/babel-plugin/__tests__/validation-stylex-create-test.js
Outdated
Show resolved
Hide resolved
| // `stylex.create` calls | ||
| +styleMap: Map<string, CompiledNamespaces> = new Map(); | ||
| +styleVars: Map<string, NodePath<>> = new Map(); | ||
| +inlineStylesCache: Map<string, FlatCompiledStyles> = new Map(); |
There was a problem hiding this comment.
What is this? Why is it needed?
- utility-styles/babel-transform.js: transforms css.display.flex → { display: 'flex' }
- babel-plugin/stylex-props.js: compiles raw objects using styleXCreateSet
- No dependency on @stylexjs/shared refactor (uses ../shared)
- All 797 tests pass
- Rename package from @stylexjs/utility-styles to @stylexjs/atoms - Update all imports and references in babel-plugin - Update stylex package dependency and re-export - Fix type definitions to be compatible with stylex.props() - Update test descriptions and imports
fc6cd07 to
fb5a7ae
Compare
Implementation
Adding support for inline styles authoring with a new
@stylexjs/atomspackage. This allows you to write styles inline instylex.props()that are pre-compiled within the props visitor using much of thecreatelogic 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.createnamespaces for the majority of usecases for readability/maintainability reasons.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
Propertiestype from estree for type checking for a first pass, but there might be something better we can use.Testing
Style types:
Tested within docs page the above +
Integration work: