Normalize `@supports` queries
- Lingua principale
- JavaScript
- Stelle
- 10.3k
- Fork
- 481
- Merge medio
- 3g 8h
- PR unite (30g)
- 13
Descrizione
`@supports` is used in Styles to check support for certain features. However, it is possible to check for the same feature in multiple ways. For example, all of these are valid ways to check for the existence of the `dvh` unit.
```css
@supports (height: 100dvh) {}
@supports (height: 1dvh) {}
@supports (min-height: 1dvh) {}
@supports (min-height: 50dvh) {}
```
All of these work in StyleX today. However, if the developer is not careful to use the same check in different parts of the codebase, the generated CSS will have unnecessary duplication.
Is there a way we can solve this?
---
## Automatically?
Is it possible to parse the condition in `@supports` and ascertain the feature being detected with high confidence in most cases?
Perhaps, if we maintain a list of features that are likely to be tested we can detect the feature being detected in the majority of cases.
If so, we can "normalize" the `@supports` query into a single canonical form and
optimise the generated CSS.
## Explicitly?
If it is not possible to simply *detect* the intention of the developer by parsing `@supports` queries, we can instead add explicit API to stylex that can be used to detect certain feature?
So instead of having to write:
```tsx
const styles = stylex.create({
root: {
height: {
default: '100vh',
'@supports (height: 100dvh)': '100dvh',
},
},
});
```
A developer may be able to write:
```tsx
const styles = stylex.create({
root: {
height: {
default: '100vh',
[stylex.supports.dvh]: '100dvh',
},
},
});
```
----
The first option is preferable because it doesn't bloat the StyleX API any further and doesn't put the responsibility on the developer to ensure they always use the API from StyleX in order to get the most optimised CSS.
Guida per i contributori
Apri la guida per i contributori
Valutazione
Questa issue non è ancora stata valutata.