[Flight] Encode server rendered host components as array tuples #18273
Conversation
facebook-github-bot
added
CLA Signed
React Core Team
This replaces the HTML renderer with instead resolving host elements into
arrays tagged with the react.element symbol. These turn into proper
React Elements on the client.
The symbol is encoded as the magical value "$". This has security implications
so this special value needs to remain escaped for other strings.
We could just encode the element as {$$typeof: "$", key: key props: props}
but that's a lot more bytes. So instead I encode it as:
["$", key, props] and then convert it back.
It would be nicer if React's reconciler could just accept these tuples.
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 47df380:
|
sebmarkbage
force-pushed
the
flightssrdep
branch
from
c976ee9 to
47df380
Compare
Details of bundled changes.Comparing: 99d7371...47df380 react-flight-dom-relay
react-flight-dom-webpack
react-client
react-server
Size changes (experimental) |
Details of bundled changes.Comparing: 99d7371...47df380 react-flight-dom-relay
react-flight-dom-webpack
react-client
react-server
Size changes (stable) |
| // TODO: Consider having React just directly accept these arrays as elements. | ||
| // Or even change the ReactElement type to be an array. | ||
| return createElement(tuple[1], tuple[2], tuple[3]); |
There was a problem hiding this comment.
With that change we'd just be able to pass arrays through without deserializing, right? Though we'd still call this function on the props element, right? Or I guess those are flattened(?). The overall architecture makes sense but i'm still catching up on the details of each stage in the expansion, serialization, deserialization, and rendering.
There was a problem hiding this comment.
There is still a deserialization step for the strings. String values starting with $ have special meaning so we need to deserialize those but we also need to unescape the user space strings that start with $.
JSON.parse materializes all objects and arrays in the JSON and then traverses over them by mutating them with new values. Which we'd still need to do to replace "$" with the symbol and replace references to reused or future values (i.e. "$12345" to their materialized value).
The benefit would be that we'd reuse the array already created by JSON.parse and just mutate the first slot from a string to a symbol.
We need the symbol to avoid the XSS potential in #3473.
The problem is that if this value gets passed into a render function and then returned from the render, we don't know if that came from Flight on the server or user provided JSON.
props: { userdata: ["$", "script", {children: "alert('p0wned')"}] }
So I solve this by escaping the "$" to "$$" in user provided data. At some point, I need to unescape it though so code can read from it. That's where deserialization comes in.
It's also used for references and I expect us to use it for more things.
In the raw Flight streaming model, this is done using the second argument to JSON.parse so it's kind of inline with the parser which (I hope) is very fast.
The issue with the Relay layering is that we currently have to do a second traversal. We could possibly avoid that if we were hooked in somehow to the same JSON.parse that Relay uses or any other pre-existing traversals.
There was a problem hiding this comment.
TIL that JSON.parse takes a second argument, i've never had a use-case for that but this is a great one.
The issue with the Relay layering is that we currently have to do a second traversal. We could possibly avoid that if we were hooked in somehow to the same JSON.parse that Relay uses or any other pre-existing traversals.
Cool. Note that Relay doesn't directly call JSON.parse - that's up to the user-provided network layer - so it should be possible for us to integrate the Flight deserialization into our internal network layer (and for folks in OSS to do the same) to avoid a double traversal.
👍
Would be cleaner conceptually and also faster - are there any particular concerns or challenges to doing that? |
There are challenges to changing existing React Elements. Mostly because people read from them using We could add these as a new type of element though. It'll mean they break similar traversal mechanisms that check for isArray or iterable etc. But it's plausible. |
This replaces the HTML renderer with instead resolving host elements into arrays tagged with the
react.elementsymbol. These turn into proper React Elements on the client.The symbol is encoded as the magical value
"$". This has security implications so this special value needs to remain escaped for other strings.We could just encode the element as
{$$typeof: "$", type: type, key: key props: props}but that's a lot more bytes. So instead I encode it as["$", type, key, props]and then convert it back on the client.In a follow up I intend to encode Block Pairs ("thunks") as
["@", render, data].It would be nicer if React's reconciler could just accept these tuples directly. We should consider that as part of the deprecation work around elements.