patricktree.me
forked from
danabra.mov/overreacted
my blog https://overreacted.io
wip
danabra.mov
+11
-23
public/untitled/index.md
+11
-23
public/untitled/index.md
···
36
36
}
37
37
```
38
38
39
-
To make this work, let's say that whenever the HTML is sent over the network--that is, *serialized*--all custom tags get replaced with the output of their functions:
39
+
To make this work, let's say that whenever the HTML is sent over the network--that is, *serialized*--the server must replace those tags with the output they return:
40
40
41
41
```js {3}
42
42
<html>
···
56
56
57
57
---
58
58
59
-
### Parameters
59
+
### Attributes
60
60
61
-
Functions take parameters.
62
-
63
-
Let's support passing and receiving them:
61
+
Let's support passing attributes to tags and interpolating values into the markup.
64
62
65
63
```js {3-4,9}
66
64
<html>
···
75
73
}
76
74
```
77
75
78
-
Of course, there's no reason why those parameters have to be *strings*.
76
+
Of course, there's no reason why those arguments have to be *strings*.
79
77
80
-
We might want to pass an object to `Greeting`:
78
+
We might want to pass an object to `Greeting` instead:
81
79
82
80
```js {3-4,10-12}
83
81
<html>
···
98
96
99
97
Objects let us group related stuff together.
100
98
101
-
Suppose we wanted to *send* the HTML above to the browser. The first step, as we specified earlier, would involve replacing custom tags with their output:
99
+
According to the [earlier rule](#tags), *serializing* the HTML above would produce:
102
100
103
-
```js {3,4}
101
+
```js
104
102
<html>
105
103
<body>
106
104
<p style={{ color: 'purple' }}>Hello, Alice</p>
···
117
115
118
116
### Objects
119
117
120
-
The "real" HTML we know and love has no first-class notion of objects. If we wanted to output some "real" HTML, we'd have to turn them into `style` strings:
118
+
The "real" HTML we know and love has no first-class notion of objects. If we wanted to output some "real" HTML, we'd have to turn `style` into a string:
121
119
122
120
```js {3,4}
123
121
<html>
···
128
126
</html>
129
127
```
130
128
131
-
But we don't *have to* turn our "imaginary" HTML into "real" HTML right away. We can stay in the imaginary land for a bit longer by turning *the entire thing* into JSON.
132
-
133
-
Note how, in this format, `style` can remain completely intact as an object within:
129
+
But if we're reimagining HTML, we don't have to abide by the same limitations. For example, we could decide that our imaginary HTML *serializes into* JSON:
134
130
135
131
```js {6,10}
136
132
["html", {
···
149
145
}]
150
146
```
151
147
152
-
We can *then* easily turn this JSON into the "real" HTML if we want. But JSON is a *richer* representation because it preserves objects in a way that is easy to parse.
148
+
This lets us keep the `style` objects--*or any objects we might want to send*--intact.
153
149
154
-
This strange JSON representation isn't particularly interesting or useful yet. But going forward, we'll co-evolve these two representations. In fact, we'll consider the JSON representation to be the primary one because it preserves the most original information--notably, *it preserves objects.* We'll think of the "real" HTML representation as secondary because it can always be computed from that JSON.
155
-
156
-
In other words, we have a little pipeline:
157
-
158
-
1. *Imaginary HTML:* The language we are inventing.
159
-
1. *JSON:* The primary output format of our language.
160
-
1. *Real HTML:* What browsers can handle directly.
161
-
162
-
Let's see how each piece evolves with new requirements.
150
+
This strange JSON representation isn't particularly interesting or useful yet. But going forward, we'll consider this representation as our primary output format. We can always generate "real" HTML *from* this representation, but not vice versa.
163
151
164
152
---
165
153