[babel-plugin] Don't use Custom Properties to implement all dynamic styles
Describe the feature request
When using inline styles directly, you don't incur the runtime cost of using custom properties to back the dynamic values of properties. For most dynamic use cases, we can simply render inline styles without using custom properties or creating additional generated CSS. There are runtime and bundle size wins to be had there.
Just adding some details for this task.
When inline styles are possible
- We can use inline styles directly for longhand CSS properties
- We cannot safely use inline styles for CSS shorthands because we need shorthand styles to have a lower specificity than longhand styles.
- This is only possible if we assume there is no usage of the legacy patterns of
:hoverand@mediaqueries. (i.e, using them outside the CSS property)
The trade-offs
- We are currently discussing a feature to automatically detect CSS variables that are never re-assigned and inline their usage (treat them like a constant).
- This would no longer be possible if we use inline styles for dynamic styles as we would not be able to have global knowledge by reading the generated CSS file.
- However, we should be able to make this work an explicit
stylex.defineConstsAPI
- Using global CSS selectors to override StyleX styles may break due to specificity change.
- we can warn them, discourage this pattern and ask them to use
!importantas an escape hatch
- we can warn them, discourage this pattern and ask them to use
Performance
- A recent investigation suggest that inline styles are just as fast or faster than using CSS.
- There is a cost of serializing objects to strings within React, but we need inline styles either way, so there is no regression on this
- The styles are not cache-able, but this is fine because the values are dynamic anyway.
- There is currently no evidence suggesting any style engine performance regression when mixing atomic CSS and inline styles.
We are currently working on implementing a feature to automatically detect CSS variables that are never re-assigned and inline their usage...
Is this being worked (who is "we") on or just promised? What does "inline their usage" mean in this context - is it the same as https://github.com/facebook/stylex/issues/737 or something else?
Using global CSS selectors to override StyleX styles may break...
Global CSS selectors? I don't follow
A recent investigation suggest that inline styles are just as fast or faster than using CSS.
What's the relevance here?
is it the same as #737 or something else?
No, this is to detect CSS variables defined with stylex.defineVars that are never re-assigned and inlining them in the generated CSS. We're still only discussing this. (I updated my comment above). This is one of the ideas Nitish and I talked about after finding out that using too many CSS variables can cause too much RAM usage.
We obviously want to work stylex.defineConsts, but wondering if this kind of optimization might be a good thing to add that doesn't depend on you manually deciding if a value needs to be a variable or a constant ahead of time.
Global CSS selectors? I don't follow
There are some rare cases in our codebase where we use CSS files to override the "base" styles applied by StyleX.
What's the relevance here?
A lot of devs assume inline styles are slower. This is just evidence that shows that inline styles are not slower than atomic CSS.