Skip to content

Commit 9275d6f

Browse files
committed
first version of CSSOM RFC
1 parent 6db1582 commit 9275d6f

File tree

1 file changed

+102
-0
lines changed

1 file changed

+102
-0
lines changed

text/0000-cssom.md

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
- Start Date: 2020-04-20
2+
- RFC PR:
3+
- React Issue:
4+
5+
# Summary
6+
7+
I know it's a long-lasting and controversial topic and probably not the highest priority for the team right now, but let me try to create the first **simplified** vision for a CSS implementation we all could agree on.
8+
9+
CSS-in-JS like React is on a dual mission, supporting both complex apps and small(ish) sites. This has created a big divide in the community because of the very different needs that these types of projects have. Like React, CSS-in-JS was born out of the need to reduce the complexity of maintaining large applications.
10+
11+
While there are many options for authoring CSS, it is super tiresome to convince a team to use a particular approach. It creates a big divide and lots of frustration. While there is a huge value in not having a built-in solution and giving the space to 3rd party libs to thrive and experiment, the friction and frustration for not having a good built-in approach that covers 90% of use cases is real.
12+
13+
## Motivation
14+
15+
### Goals
16+
17+
- High-performance static styles via CSSOM. Rendering CSS only once and reusing across components and updates allows avoiding additional work within components render cycle.
18+
- Lists - inline styles have no way to be reused across list elements, where typically styles are repeated.
19+
- Support the full CSS spec. Inline styles are limited to [CSSStyleDeclaration](https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration) and we need to support the full spec on the web.
20+
- Adhere to React's component model and the upcoming Suspense architecture.
21+
22+
### Non-goals
23+
24+
- Enforcing CSS-in-JS over vanilla CSS or css-modules (you can still use className)
25+
- Replacing every possible interface/idea CSS-in-JS libs came up with
26+
27+
# Detailed design
28+
29+
### Tagged templates
30+
31+
- familiar syntax
32+
- syntax highlighting
33+
- linting
34+
- ability to return a data structure that React can identify, not just a string
35+
- interpolations
36+
37+
```js
38+
import { css } from "react-cssom";
39+
const buttonStyle = css`
40+
color: red;
41+
`; // {css: 'color: red;'}
42+
43+
render(<button style={buttonStyle}>x</button>);
44+
```
45+
46+
### Using style prop for both inline and CSSOM styles
47+
48+
Since we can return from the tag function any data structure we want, we can identify styles created using our `css` function and we have no problem accepting both types of styles.
49+
50+
Using the `style` prop allows us to be flexible in the future about how React wants to optimize and treat this interface.
51+
52+
That being said using a new prop like `css` is also an option:
53+
54+
```js
55+
render(<button css={buttonStyle}>x</button>);
56+
```
57+
58+
### Babel plugin
59+
60+
Babel plugin can be optional and can enable advanced features like:
61+
62+
- vendor prefixing
63+
- optimizations
64+
- other preprocessing options e.g. using PostCSS
65+
66+
After babel plugin the call into `css` tag function can be removed and the result of the above example can be compiled to:
67+
68+
```js
69+
const buttonStyle = { css: `color: red;` };
70+
render(<button style={buttonStyle}>x</button>);
71+
```
72+
73+
# Drawbacks
74+
75+
- we are adding a new area of responsibility to React, which will require more work to maintain it, but hopefully can be parallelized
76+
- it inevitably will raise the discussions about how React is enforcing CSS-in-JS, so we will have to prepare a good answer
77+
- there are several of unresolved features listed below, which will have to be addressed over time
78+
79+
# Alternatives
80+
81+
This is a very simple initial version, so it's not as feature-rich as some other CSS-in-JS solutions, but it has a potential to cover more use cases later.
82+
83+
It is not a replacement for react-native approach.
84+
85+
It is not a replacement for any entirely different approaches like SwiftUI.
86+
87+
# Adoption strategy
88+
89+
It is not a breaking change.
90+
91+
# How we teach this
92+
93+
It is a primitive interface for passing CSS to React to integrate with component's lifecycle. It can be also a way for babel plugins and compile-time processing of CSS for React components.
94+
95+
# Unresolved questions
96+
97+
- Composition
98+
- Overrides
99+
- Dynamic or state-based styling
100+
- Theming
101+
- Alternative object-based syntax
102+
- Compatibility with react-native

0 commit comments

Comments
 (0)