maxjhandsome
/
react
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
react/packages/react-server/src/ReactFlightServerConfigStre...

175 lines
4.0 KiB
JavaScript
Raw Normal View History

[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
/**
[Codemod] Update copyright header to Meta (#25315) * Facebook -> Meta in copyright rg --files | xargs sed -i 's#Copyright (c) Facebook, Inc. and its affiliates.#Copyright (c) Meta Platforms, Inc. and affiliates.#g' * Manual tweaks
2022-10-18 23:19:24 +08:00
* Copyright (c) Meta Platforms, Inc. and affiliates.
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @flow
*/
// This file is an intermediate layer to translate between Flight
// calls to stream output over a binary stream.
/*
FLIGHT PROTOCOL GRAMMAR
Response
[Flight] Add support for Module References in transport protocol (#20121) * Refactor Flight to require a module reference to be brand checked This exposes a host environment (bundler) specific hook to check if an object is a module reference. This will be used so that they can be passed directly into Flight without needing additional wrapper objects. * Emit module references as a special type of value We already have JSON and errors as special types of "rows". This encodes module references as a special type of row value. This was always the intention because it allows those values to be emitted first in the stream so that as a large models stream down, we can start preloading as early as possible. We preload the module when they resolve but we lazily require them as they are referenced. * Emit module references where ever they occur This emits module references where ever they occur. In blocks or even directly in elements. * Don't special case the root row I originally did this so that a simple stream is also just plain JSON. However, since we might want to emit things like modules before the root module in the stream, this gets unnecessarily complicated. We could add this back as a special case if it's the first byte written but meh. * Update the protocol * Add test for using a module reference as a client component * Relax element type check Since Flight now accepts a module reference as returned by any bundler system, depending on the renderer running. We need to drastically relax the check to include all of them. We can add more as we discover them. * Move flow annotation Seems like our compiler is not happy with stripping this. * Some bookkeeping bug * Can't use the private field to check
2020-10-30 08:57:31 +08:00
- RowSequence
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
RowSequence
- Row RowSequence
- Row
Row
- "J" RowID JSONData
[Flight] Add support for Module References in transport protocol (#20121) * Refactor Flight to require a module reference to be brand checked This exposes a host environment (bundler) specific hook to check if an object is a module reference. This will be used so that they can be passed directly into Flight without needing additional wrapper objects. * Emit module references as a special type of value We already have JSON and errors as special types of "rows". This encodes module references as a special type of row value. This was always the intention because it allows those values to be emitted first in the stream so that as a large models stream down, we can start preloading as early as possible. We preload the module when they resolve but we lazily require them as they are referenced. * Emit module references where ever they occur This emits module references where ever they occur. In blocks or even directly in elements. * Don't special case the root row I originally did this so that a simple stream is also just plain JSON. However, since we might want to emit things like modules before the root module in the stream, this gets unnecessarily complicated. We could add this back as a special case if it's the first byte written but meh. * Update the protocol * Add test for using a module reference as a client component * Relax element type check Since Flight now accepts a module reference as returned by any bundler system, depending on the renderer running. We need to drastically relax the check to include all of them. We can add more as we discover them. * Move flow annotation Seems like our compiler is not happy with stripping this. * Some bookkeeping bug * Can't use the private field to check
2020-10-30 08:57:31 +08:00
- "M" RowID JSONModuleData
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
- "H" RowID HTMLData
- "B" RowID BlobData
- "U" RowID URLData
- "E" RowID ErrorData
RowID
- HexDigits ":"
HexDigits
- HexDigit HexDigits
- HexDigit
HexDigit
- 0-F
URLData
- (UTF8 encoded URL) "\n"
ErrorData
- (UTF8 encoded JSON: {message: "...", stack: "..."}) "\n"
JSONData
- (UTF8 encoded JSON) "\n"
- String values that begin with $ are escaped with a "$" prefix.
- References to other rows are encoding as JSONReference strings.
JSONReference
- "$" HexDigits
HTMLData
- ByteSize (UTF8 encoded HTML)
BlobData
- ByteSize (Binary Data)
ByteSize
- (unsigned 32-bit integer)
*/
// TODO: Implement HTMLData, BlobData and URLData.
Split out ServerReferenceMetadata into Id and Bound Arguments (#26351) This is just moving some stuff around and renaming things. This tuple is opaque to the Flight implementation and we should probably encode it separately as a single string instead of a model object. The term "Metadata" isn't the same as when used for ClientReferences so it's not really the right term anyway. I also made it optional since a bound function with no arguments bound is technically different than a raw instance of that function (it's a clone). I also renamed the type ReactModel to ReactClientValue. This is the generic serializable type for something that can pass through the serializable boundary from server to client. There will be another one for client to server. I also filled in missing classes and ensure the serializable sub-types are explicit. E.g. Array and Thenable.
2023-03-09 12:45:55 +08:00
import type {
Request,
ReactClientValue,
} from 'react-server/src/ReactFlightServer';
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
Allow the streaming config to decide how to precompute or compute chunks (#21008) Some legacy environments can not encode non-strings. Those would specify both as strings. They'll throw for binary data. Some environments have to encode strings (like web streams). Those would encode both as uint8array. Some environments (like Node) can do either. It can be beneficial to leave things as strings in case the native stream can do something smart with it.
2021-03-16 01:36:23 +08:00
import {stringToChunk} from './ReactServerStreamConfig';
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
Allow the streaming config to decide how to precompute or compute chunks (#21008) Some legacy environments can not encode non-strings. Those would specify both as strings. They'll throw for binary data. Some environments have to encode strings (like web streams). Those would encode both as uint8array. Some environments (like Node) can do either. It can be beneficial to leave things as strings in case the native stream can do something smart with it.
2021-03-16 01:36:23 +08:00
import type {Chunk} from './ReactServerStreamConfig';
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
Allow the streaming config to decide how to precompute or compute chunks (#21008) Some legacy environments can not encode non-strings. Those would specify both as strings. They'll throw for binary data. Some environments have to encode strings (like web streams). Those would encode both as uint8array. Some environments (like Node) can do either. It can be beneficial to leave things as strings in case the native stream can do something smart with it.
2021-03-16 01:36:23 +08:00
export type {Destination, Chunk} from './ReactServerStreamConfig';
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
const stringify = JSON.stringify;
function serializeRowHeader(tag: string, id: number) {
Refactor Flight Encoding (#26082) This is just shifting around some encoding strategies for Flight in preparation for more types. ``` S1:"react.suspense" J2:["$", "$1", {children: "@3"}] J3:"Hello" ``` ``` 1:"$Sreact.suspense" 2:["$", "$1", {children: "$L3"}] 3:"Hello" ```
2023-02-01 01:41:36 +08:00
return id.toString(16) + ':' + tag;
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
}
[Flight] Implement error digests for Flight runtime and expose errorInfo in getDerivedStateFromError (#25302) Similar to Fizz, Flight now supports a return value from the user provided onError option. If a value is returned from onError it will be serialized and provided to the client. The digest is stashed on the constructed Error on the client as .digest
2022-09-24 04:19:29 +08:00
export function processErrorChunkProd(
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
request: Request,
id: number,
[Flight] Implement error digests for Flight runtime and expose errorInfo in getDerivedStateFromError (#25302) Similar to Fizz, Flight now supports a return value from the user provided onError option. If a value is returned from onError it will be serialized and provided to the client. The digest is stashed on the constructed Error on the client as .digest
2022-09-24 04:19:29 +08:00
digest: string,
): Chunk {
if (__DEV__) {
// These errors should never make it into a build so we don't need to encode them in codes.json
// eslint-disable-next-line react-internal/prod-error-codes
throw new Error(
'processErrorChunkProd should never be called while in development mode. Use processErrorChunkDev instead. This is a bug in React.',
);
}
const errorInfo: any = {digest};
const row = serializeRowHeader('E', id) + stringify(errorInfo) + '\n';
return stringToChunk(row);
}
export function processErrorChunkDev(
request: Request,
id: number,
digest: string,
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
message: string,
stack: string,
): Chunk {
[Flight] Implement error digests for Flight runtime and expose errorInfo in getDerivedStateFromError (#25302) Similar to Fizz, Flight now supports a return value from the user provided onError option. If a value is returned from onError it will be serialized and provided to the client. The digest is stashed on the constructed Error on the client as .digest
2022-09-24 04:19:29 +08:00
if (!__DEV__) {
// These errors should never make it into a build so we don't need to encode them in codes.json
// eslint-disable-next-line react-internal/prod-error-codes
throw new Error(
'processErrorChunkDev should never be called while in production mode. Use processErrorChunkProd instead. This is a bug in React.',
);
}
const errorInfo: any = {digest, message, stack};
Enable prefer-const lint rules (#18451) * Enable prefer-const rule Stylistically I don't like this but Closure Compiler takes advantage of this information. * Auto-fix lints * Manually fix the remaining callsites
2020-04-02 03:35:52 +08:00
const row = serializeRowHeader('E', id) + stringify(errorInfo) + '\n';
Allow the streaming config to decide how to precompute or compute chunks (#21008) Some legacy environments can not encode non-strings. Those would specify both as strings. They'll throw for binary data. Some environments have to encode strings (like web streams). Those would encode both as uint8array. Some environments (like Node) can do either. It can be beneficial to leave things as strings in case the native stream can do something smart with it.
2021-03-16 01:36:23 +08:00
return stringToChunk(row);
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
}
export function processModelChunk(
request: Request,
id: number,
Split out ServerReferenceMetadata into Id and Bound Arguments (#26351) This is just moving some stuff around and renaming things. This tuple is opaque to the Flight implementation and we should probably encode it separately as a single string instead of a model object. The term "Metadata" isn't the same as when used for ClientReferences so it's not really the right term anyway. I also made it optional since a bound function with no arguments bound is technically different than a raw instance of that function (it's a clone). I also renamed the type ReactModel to ReactClientValue. This is the generic serializable type for something that can pass through the serializable boundary from server to client. There will be another one for client to server. I also filled in missing classes and ensure the serializable sub-types are explicit. E.g. Array and Thenable.
2023-03-09 12:45:55 +08:00
model: ReactClientValue,
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
): Chunk {
Upgrade Flow to 0.201 (#26326) Small Flow upgrade to keep us current.
2023-03-06 23:33:22 +08:00
// $FlowFixMe[incompatible-type] stringify can return null
Update to Flow from 0.97 to 0.122 (#25204) * flow 0.122 * update ReactModel type
2022-09-08 23:46:07 +08:00
const json: string = stringify(model, request.toJSON);
Refactor Flight Encoding (#26082) This is just shifting around some encoding strategies for Flight in preparation for more types. ``` S1:"react.suspense" J2:["$", "$1", {children: "@3"}] J3:"Hello" ``` ``` 1:"$Sreact.suspense" 2:["$", "$1", {children: "$L3"}] 3:"Hello" ```
2023-02-01 01:41:36 +08:00
const row = id.toString(16) + ':' + json + '\n';
Allow the streaming config to decide how to precompute or compute chunks (#21008) Some legacy environments can not encode non-strings. Those would specify both as strings. They'll throw for binary data. Some environments have to encode strings (like web streams). Those would encode both as uint8array. Some environments (like Node) can do either. It can be beneficial to leave things as strings in case the native stream can do something smart with it.
2021-03-16 01:36:23 +08:00
return stringToChunk(row);
[Flight] Add support for Module References in transport protocol (#20121) * Refactor Flight to require a module reference to be brand checked This exposes a host environment (bundler) specific hook to check if an object is a module reference. This will be used so that they can be passed directly into Flight without needing additional wrapper objects. * Emit module references as a special type of value We already have JSON and errors as special types of "rows". This encodes module references as a special type of row value. This was always the intention because it allows those values to be emitted first in the stream so that as a large models stream down, we can start preloading as early as possible. We preload the module when they resolve but we lazily require them as they are referenced. * Emit module references where ever they occur This emits module references where ever they occur. In blocks or even directly in elements. * Don't special case the root row I originally did this so that a simple stream is also just plain JSON. However, since we might want to emit things like modules before the root module in the stream, this gets unnecessarily complicated. We could add this back as a special case if it's the first byte written but meh. * Update the protocol * Add test for using a module reference as a client component * Relax element type check Since Flight now accepts a module reference as returned by any bundler system, depending on the renderer running. We need to drastically relax the check to include all of them. We can add more as we discover them. * Move flow annotation Seems like our compiler is not happy with stripping this. * Some bookkeeping bug * Can't use the private field to check
2020-10-30 08:57:31 +08:00
}
Abort Flight (#24754) Add aborting to the Flight Server. This encodes the reason as an "error" row that gets thrown client side. These are still exposed in prod which is a follow up we'll still have to do to encode them as digests instead. The error is encoded once and then referenced by each row that needs to be updated.
2022-06-19 23:05:41 +08:00
export function processReferenceChunk(
request: Request,
id: number,
reference: string,
): Chunk {
const json = stringify(reference);
Refactor Flight Encoding (#26082) This is just shifting around some encoding strategies for Flight in preparation for more types. ``` S1:"react.suspense" J2:["$", "$1", {children: "@3"}] J3:"Hello" ``` ``` 1:"$Sreact.suspense" 2:["$", "$1", {children: "$L3"}] 3:"Hello" ```
2023-02-01 01:41:36 +08:00
const row = id.toString(16) + ':' + json + '\n';
Abort Flight (#24754) Add aborting to the Flight Server. This encodes the reason as an "error" row that gets thrown client side. These are still exposed in prod which is a follow up we'll still have to do to encode them as digests instead. The error is encoded once and then referenced by each row that needs to be updated.
2022-06-19 23:05:41 +08:00
return stringToChunk(row);
}
Enable passing Server References from Server to Client (#26124) This is the first of a series of PRs, that let you pass functions, by reference, to the client and back. E.g. through Server Context. It's like client references but they're opaque on the client and resolved on the server. To do this, for security, you must opt-in to exposing these functions to the client using the `"use server"` directive. The `"use client"` directive lets you enter the client from the server. The `"use server"` directive lets you enter the server from the client. This works by tagging those functions as Server References. We could potentially expand this to other non-serializable or stateful objects too like classes. This only implements server->server CJS imports and server->server ESM imports. We really should add a loader to the webpack plug-in for client->server imports too. I'll leave closures as an exercise for integrators. You can't "call" a client reference on the server, however, you can "call" a server reference on the client. This invokes a callback on the Flight client options called `callServer`. This lets a router implement calling back to the server. Effectively creating an RPC. This is using JSON for serializing those arguments but more utils coming from client->server serialization.
2023-02-10 08:45:05 +08:00
export function processImportChunk(
[Flight] Add support for Module References in transport protocol (#20121) * Refactor Flight to require a module reference to be brand checked This exposes a host environment (bundler) specific hook to check if an object is a module reference. This will be used so that they can be passed directly into Flight without needing additional wrapper objects. * Emit module references as a special type of value We already have JSON and errors as special types of "rows". This encodes module references as a special type of row value. This was always the intention because it allows those values to be emitted first in the stream so that as a large models stream down, we can start preloading as early as possible. We preload the module when they resolve but we lazily require them as they are referenced. * Emit module references where ever they occur This emits module references where ever they occur. In blocks or even directly in elements. * Don't special case the root row I originally did this so that a simple stream is also just plain JSON. However, since we might want to emit things like modules before the root module in the stream, this gets unnecessarily complicated. We could add this back as a special case if it's the first byte written but meh. * Update the protocol * Add test for using a module reference as a client component * Relax element type check Since Flight now accepts a module reference as returned by any bundler system, depending on the renderer running. We need to drastically relax the check to include all of them. We can add more as we discover them. * Move flow annotation Seems like our compiler is not happy with stripping this. * Some bookkeeping bug * Can't use the private field to check
2020-10-30 08:57:31 +08:00
request: Request,
id: number,
Split out ServerReferenceMetadata into Id and Bound Arguments (#26351) This is just moving some stuff around and renaming things. This tuple is opaque to the Flight implementation and we should probably encode it separately as a single string instead of a model object. The term "Metadata" isn't the same as when used for ClientReferences so it's not really the right term anyway. I also made it optional since a bound function with no arguments bound is technically different than a raw instance of that function (it's a clone). I also renamed the type ReactModel to ReactClientValue. This is the generic serializable type for something that can pass through the serializable boundary from server to client. There will be another one for client to server. I also filled in missing classes and ensure the serializable sub-types are explicit. E.g. Array and Thenable.
2023-03-09 12:45:55 +08:00
clientReferenceMetadata: ReactClientValue,
[Flight] Add support for Module References in transport protocol (#20121) * Refactor Flight to require a module reference to be brand checked This exposes a host environment (bundler) specific hook to check if an object is a module reference. This will be used so that they can be passed directly into Flight without needing additional wrapper objects. * Emit module references as a special type of value We already have JSON and errors as special types of "rows". This encodes module references as a special type of row value. This was always the intention because it allows those values to be emitted first in the stream so that as a large models stream down, we can start preloading as early as possible. We preload the module when they resolve but we lazily require them as they are referenced. * Emit module references where ever they occur This emits module references where ever they occur. In blocks or even directly in elements. * Don't special case the root row I originally did this so that a simple stream is also just plain JSON. However, since we might want to emit things like modules before the root module in the stream, this gets unnecessarily complicated. We could add this back as a special case if it's the first byte written but meh. * Update the protocol * Add test for using a module reference as a client component * Relax element type check Since Flight now accepts a module reference as returned by any bundler system, depending on the renderer running. We need to drastically relax the check to include all of them. We can add more as we discover them. * Move flow annotation Seems like our compiler is not happy with stripping this. * Some bookkeeping bug * Can't use the private field to check
2020-10-30 08:57:31 +08:00
): Chunk {
Upgrade Flow to 0.201 (#26326) Small Flow upgrade to keep us current.
2023-03-06 23:33:22 +08:00
// $FlowFixMe[incompatible-type] stringify can return null
Enable passing Server References from Server to Client (#26124) This is the first of a series of PRs, that let you pass functions, by reference, to the client and back. E.g. through Server Context. It's like client references but they're opaque on the client and resolved on the server. To do this, for security, you must opt-in to exposing these functions to the client using the `"use server"` directive. The `"use client"` directive lets you enter the client from the server. The `"use server"` directive lets you enter the server from the client. This works by tagging those functions as Server References. We could potentially expand this to other non-serializable or stateful objects too like classes. This only implements server->server CJS imports and server->server ESM imports. We really should add a loader to the webpack plug-in for client->server imports too. I'll leave closures as an exercise for integrators. You can't "call" a client reference on the server, however, you can "call" a server reference on the client. This invokes a callback on the Flight client options called `callServer`. This lets a router implement calling back to the server. Effectively creating an RPC. This is using JSON for serializing those arguments but more utils coming from client->server serialization.
2023-02-10 08:45:05 +08:00
const json: string = stringify(clientReferenceMetadata);
Refactor Flight Encoding (#26082) This is just shifting around some encoding strategies for Flight in preparation for more types. ``` S1:"react.suspense" J2:["$", "$1", {children: "@3"}] J3:"Hello" ``` ``` 1:"$Sreact.suspense" 2:["$", "$1", {children: "$L3"}] 3:"Hello" ```
2023-02-01 01:41:36 +08:00
const row = serializeRowHeader('I', id) + json + '\n';
Allow the streaming config to decide how to precompute or compute chunks (#21008) Some legacy environments can not encode non-strings. Those would specify both as strings. They'll throw for binary data. Some environments have to encode strings (like web streams). Those would encode both as uint8array. Some environments (like Node) can do either. It can be beneficial to leave things as strings in case the native stream can do something smart with it.
2021-03-16 01:36:23 +08:00
return stringToChunk(row);
[Flight] Encode Symbols as special rows that can be referenced by models … (#20171) * Encode Symbols as special rows that can be referenced by models If a symbol was extracted from Symbol.for(...) then we can reliably recreate the same symbol on the client. S123:"react.suspense" M456:{mySymbol: '$123'} This doesn't suffer from the XSS problem because you have to write actual code to create one of these symbols. That problem is only a problem because values pass through common other usages of JSON which are not secure. Since React encodes its built-ins as symbols, we can now use them as long as its props are serializable. Like Suspense. * Refactor resolution to avoid memo hack Going through createElement isn't quite equivalent for ref and key in props. * Reuse symbol ids that have already been written earlier in the stream
2020-11-11 11:56:50 +08:00
}
[Float][Flight] Flight support for Float (#26502) Stacked on #26557 Supporting Float methods such as ReactDOM.preload() are challenging for flight because it does not have an easy means to convey direct executions in other environments. Because the flight wire format is a JSON-like serialization that is expected to be rendered it currently only describes renderable elements. We need a way to convey a function invocation that gets run in the context of the client environment whether that is Fizz or Fiber. Fiber is somewhat straightforward because the HostDispatcher is always active and we can just have the FlightClient dispatch the serialized directive. Fizz is much more challenging becaue the dispatcher is always scoped but the specific request the dispatch belongs to is not readily available. Environments that support AsyncLocalStorage (or in the future AsyncContext) we will use this to be able to resolve directives in Fizz to the appropriate Request. For other environments directives will be elided. Right now this is pragmatic and non-breaking because all directives are opportunistic and non-critical. If this changes in the future we will need to reconsider how widespread support for async context tracking is. For Flight, if AsyncLocalStorage is available Float methods can be called before and after await points and be expected to work. If AsyncLocalStorage is not available float methods called in the sync phase of a component render will be captured but anything after an await point will be a noop. If a float call is dropped in this manner a DEV warning should help you realize your code may need to be modified. This PR also introduces a way for resources (Fizz) and hints (Flight) to flush even if there is not active task being worked on. This will help when Float methods are called in between async points within a function execution but the task is blocked on the entire function finishing. This PR also introduces deduping of Hints in Flight using the same resource keys used in Fizz. This will help shrink payload sizes when the same hint is attempted to emit over and over again
2023-04-22 11:45:51 +08:00
export function processHintChunk(
request: Request,
id: number,
code: string,
model: JSONValue,
): Chunk {
const json: string = stringify(model);
const row = serializeRowHeader('H' + code, id) + json + '\n';
return stringToChunk(row);
}
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
export {
scheduleWork,
flushBuffered,
beginWriting,
writeChunk,
Split writeChunk into void and return value (#23343) This function was modeled after Node streams where write returns a boolean whether to keep writing or not. I think we should probably switch this up and read desired size explicitly in appropriate places. However, in the meantime, we don't have to return a value where we're not going to use it. So I split this so that we call writeChunkAndReturn if we're going to return the boolean. This should help with the compilation so that they can be inlined.
2022-02-24 00:35:21 +08:00
writeChunkAndReturn,
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
completeWriting,
close,
[Flight] Add global onError handler (#21129) * Add onError option to Flight Server The callback is called any time an error is generated in a server component. This allows it to be logged on a server if needed. It'll still be rethrown on the client so it can be logged there too but in case it never reaches the client, here's a way to make sure it doesn't get lost. * Add fatal error handling
2021-03-30 10:36:16 +08:00
closeWithError,
[Flight] Split Streaming from Relay Implemenation (#18260) * Add ReactFlightServerConfig intermediate This just forwards to the stream version of Flight which is itself forked between Node and W3C streams. The dom-relay goes directly to the Relay config though which allows it to avoid the stream part of Flight. * Separate streaming protocol into the Stream config * Split streaming parts into the ReactFlightServerConfigStream This decouples it so that the Relay implementation doesn't have to encode the JSON to strings. Instead it can be fed the values as JSON objects and do its own encoding. * Split FlightClient into a basic part and a stream part Same split as the server. * Expose lower level async hooks to Relay This requires an external helper file that we'll wire up internally.
2020-03-11 05:55:04 +08:00
} from './ReactServerStreamConfig';