@khanacademy/wonder-blocks-data 10.0.5 → 10.1.1

package/src/__docs__/_overview_ssr_.stories.mdx

@@ -1,185 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Server-side Rendering and Hydration"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# Server-side Rendering (SSR)
-
-Wonder Blocks Data provides components, hooks, and additional APIs to make server-side rendering and hydration of asynchronous requests easier.
-
-The [`Data`](/docs/data-exports-data--page) component and the [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page) hook (which [`Data`](/docs/data-exports-data--page) uses internally) both
-support server-side rendering and hydration.
-
-These APIs have been designed to make it easy for everyday development. The developer does not need to consider the server-side process nor hydration when requiring asynchronous data. Instead, they use [`Data`](/docs/data-exports-data--page) or [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page) to get the data they need.
-
-## Integrating into server-side rendering
-
-Generally, server-side rendering has a loop that renders the page, determines what asynchronous activity needs to be resolved, resolves and caches that activity, then renders again, ensuring that as much of the page as possible has been rendered.
-
-In order for the requests made through [`Data`](/docs/data-exports-data--page) and [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page) use to be fulfilled on the server and subsequently hydrated on the client, the server responsible for rendering the page must be modified to track and capture the requests and their responses.
-
-First, Wonder Blocks Data has to be told to work in server-side mode:
-
-```ts
-import {Server} from "@khanacademy/wonder-blocks-core";
-
-Server.setServerSide();
-```
-
-By setting Wonder Blocks into server mode, requests will not be fulfilled during rendering (there would be no point since server-side rendering does not mount components and as such, cannot update the rendered component tree with the result of asynchronous requests). Instead, we are now ready to track these requests.
-
-### Tracking and fulfilling requests
-
-To track the requests, the React node being rendered must be wrapped in the [`TrackData`](/docs/data-exports-trackdata--page) component.
-
-```tsx
-const trackedElement = (
-    <TrackData>
-        {theNodeTheClientNormallyRenders}
-    </TrackData>
-);
-```
-
-The [`TrackData`](/docs/data-exports-trackdata--page) component is responsible for capturing the requests that were made during a render of the given React node. Of course to do that, we have to render the node. Rendering is usually performed by `renderToString` from the `react-dom/server` import.
-
-```ts
-import {renderToString} from "react-dom/server";
-
-renderToString(trackedElement);
-```
-
-After each render, we want to see if there are any tracked requests needing to be fulfilled. If there are, we will want to fulfill them and render again; if there are not, we are ready to finish the page rendering and move on.
-
-To determine which path to take, we can use [`hasTrackedRequestsToBeFetched`](/docs/data-exports-hastrackedrequeststobefetched--page), and then based off that result, either fulfill the requests, or finish rendering our page.
-
-```ts
-if (hasTrackedRequestsToBeFetched()) {
-    await fetchTrackedRequests();
-
-    // Render again.
-    // ...
-} else {
-    // Finish rendering the page.
-    // ...
-}
-```
-
-Internally, Wonder Blocks Data caches the responses of fulfilled requests and does not track them again. Each cycle of the rendering should occur with the same knowledge you expect the client-side to have when it performs the render, so although we want to retain our hydration cache response, we need to make sure any transient caches are cleared.
-
-Once the rendered component no longer requires any further data, the cached responses can be obtained to include in the rendered page for the client to hydrate. The hydration cache is promised by `fetchTrackedRequests()`, regardless of whether it actually had any pending requests or not.
-
-### Putting it all together
-
-> 😱 Make sure you safely embed strings in your rendered pages to avoid injection bugs. This example is brief for the purposes of illustration.
-
-A function for server-side rendering with Wonder Blocks Data could look something like this.
-
-```tsx
-import {Server} from "@khanacademy/wonder-blocks-core";
-import {
-    TrackData,
-    hasTrackedRequestsToBeFetched,
-    fetchTrackedRequests,
-    SharedCache,
-} from "@khanacademy/wonder-blocks-data";
-
-// Don't forget to import your app!
-import App from "./App.js";
-
-async function renderApp(): Promise<string> {
-    // Tell Wonder Blocks we are server-side.
-    Server.setServerSide();
-
-    // Wrap the app with our tracking code.
-    const trackedElement = (
-        <TrackData>
-            <App />
-        </TrackData>
-    );
-
-    // Now, loop around rendering and fulfilling until we have nothing left
-    // to fulfill.
-    let hydrationCache = null;
-    let renderedComponent = null;
-    do {
-        /*
-         * Each render has to be isolated, so we have to make sure we clear the
-         * shared cache used by the `useSharedCache` hook as this is transient
-         * cache that does not itself get directly hydrated.
-         */
-        SharedCache.purgeAll();
-
-        // Render the tracked component.
-        renderedComponent = renderToString(trackedElement);
-
-        if (hasTrackedRequestsToBeFetched()) {
-            // Fulfill any pending requests.
-            await fetchTrackedRequests();
-
-            // We can't leave the loop yet as we want to render the element
-            // again with the newly fulfilled data.
-            continue;
-        }
-
-
-        // We rendered with all the data fulfilled, so we can grab the
-        // hydration cache contents and exit the loop now.
-        hydrationCache = await fetchTrackedRequests();
-    } while (hydrationCache == null);
-
-    // Finally, render the page with our hydration cache and rendered
-    // component.
-    return `
-<html>
-   <head>
-         <title>My Page</title>
-         <script>
-            window.__WONDER_BLOCKS_DATA__ = ${safeStringify(hydrationCache)}
-         </script>
-         <script src="hydrate.js"></script>
-   </head>
-   <body>
-      <div id="my-react-app-root">
-         ${renderedComponent}
-      </div>
-   </body>
-</html>
-`;
-}
-```
-
-The above page is simplified for clarity - you would need to make sure all your scripts, fonts, etc. get loaded into the page. However, assuming all those things get loaded, the last piece need is signified above as the script tag importing `hydrate.js` - this is the script that will hydrate the client-side rendered component.
-
-## Hydrating on the client-side
-
-Now that you have a rendered page, the client needs to be written to properly hydrate to the exact same state as the server rendered. To do this, the hydration cache that was serialized into the page as `window.__WONDER_BLOCKS_DATA__` must be injected into the Wonder Blocks Data cache before the React `hydrate` call is made.
-
-In the previous section, this was displayed as the `hydrate.js` script. Here is what that script might look like.
-
-```tsx
-import {hydrate} from "react-dom";
-import {initializeHydrationCache} from "@khanacademy/wonder-blocks-data";
-
-// Don't forget to import your app!
-import App from "./App.js";
-
-initializeHydrationCache(window._WONDER_BLOCKS_DATA_);
-
-React.hydrate(
-    // This should match whatever was passed to the server-side rendering
-    // function, renderApp, in the previous section.
-    <App />,
-
-    // The ID of the element to host the hydrated component has to match what
-    // the server-rendered page uses.
-    document.getElementById("my-react-app-root"),
-);
-```
-
-That's it! The client-side hydration is complete. Underneath the hood, the hydration cache is used to hydrate the responses that the server used to render the page. And if you render a page that was not server-side rendered, the [`Data`](/docs/data-exports-data--page) and [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page) know exactly what to do and will make the requests client-side instead.

package/src/__docs__/_overview_testing_.stories.mdx

@@ -1,123 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Testing"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# Testing Support
-
-Wonder Blocks Data has been designed to support testing in a variety of environments including jest and storybook. In order to support the various ways in which folks need to test their code, we have considered a number of approaches to testing Wonder Blocks Data.
-
-## Spies
-If you are writing unit tests, you may just want to spy on the methods you are calling using `jest.spyOn` or similar. This can be a really easy way to intercept the request handler passed to the [`useCachedEffect`](/docs/data-exports-usecachedeffect--page) hook, for example, and check that it is the handler you expect.
-
-## Interceptors
-
-Each request used by Wonder Blocks Data has to have an identifier. The [`InterceptRequests`](/docs/data-exports-interceptrequests--page) component allows you to wrap the code under test with an interceptor. Interceptors are given the request identifier and get to choose, based off that identifier, if they want to provide their own response rather than let the original request handler deal with it.
-
-Multiple interceptors can be registered by nesting the [`InterceptRequests`](/docs/data-exports-interceptrequests--page) component as is necessary. Registered interceptors are invoked in ancestral order, with the nearest ancestor to the intercepted request being invoked first.
-
-When hooks like [`useServerEffect`](/docs/data-exports-useservereffect--page), [`useCachedEffect`](/docs/data-exports-usecachedeffect--page), or [`useHydratedEffect`](/docs/data-exports-usehydratedeffect--page) run, they get the chain of registered interceptors and chain those with the original handler in order to determine what to actually do when executing the request.
-
-This allows you to mock out requests in unit tests, stories, and other scenarios.
-
-## GqlRouter, mockGqlFetch, and RespondWith
-
-If you are testing GraphQL operations, you can configure [`GqlRouter`](/docs/data-exports-gqlrouter--page) with your own function for the `fetch` prop. However, crafting the right response to give
-the result you want is a bit tricky.
-
-```tsx
-const myFakeGqlFetch = (
-    operation: GqlOperation<TData, TVariables>,
-    variables: ?TVariables,
-    context: TContext,
-): Promise<Response> {
-    if (operation.id === "myQuery" && variables?.someVar === 5) {
-        return Promise.resolve({
-            status: 200,
-            text: () =>
-                Promise.resolve(
-                    JSON.stringify({
-                        data: {
-                            myQuery: {
-                                someField: "someValue",
-                            },
-                        },
-                    }),
-                ),
-        });
-    }
-
-    return Promise.resolve({
-        status: 404,
-        text: () => Promise.resolve(JSON.stringify({})),
-    });
-}
-
-<GqlRouter fetch={myFakeGqlFetch} defaultContext={{some: "sort of context"}}>
-    <ComponentUnderTest />
-</GqlRouter>
-```
-
-As shown above, you can interrogate parts of the requested operation to decide how to respond. However, this can get cumbersome if you have GraphQL requests nested in more complex components as each test has to mock out suitable responses for each one. To help with this the Wonder Blocks Testing package provides a [`RespondWith`](/docs/testing-exports-respondwith--page) type for defining responses that fit a specific scenario, and the [`mockGqlFetch()`](/docs/testing-exports-mockgqlfetch--page) API.
-
-```tsx
-const myFakeGqlFetch = mockGqlFetch()
-    .mockOperationOnce(
-        {
-            operation: MyQueryOperation,
-            variables: {
-                someVar: 5,
-            },
-        },
-        RespondWith.success({
-            data: {
-                myQuery: {
-                    someField: "someValue",
-                },
-            },
-        }),
-    );
-
-<GqlRouter fetch={myFakeGqlFetch} defaultContext={{some: "sort of context"}}>
-    <ComponentUnderTest />
-</GqlRouter>
-```
-
-In the above example, we now only mock our specific operation once. If something
-tries to request this data a second time, it will give an error instead. Not only that, but with a little refactoring, we can create a helper to set this mock up that others can call if they need to mock our operation for their own tests.
-
-```ts
-const mockMyQuery = (mockGqlFetchFn: GqlFetchMockFn): GqlFetchMockFn =>
-    mockGqlFetchFn()
-        .mockOperationOnce(
-            {
-                operation: MyQueryOperation,
-                variables: {
-                    someVar: 5,
-                },
-            },
-            RespondWith.success({
-                data: {
-                    myQuery: {
-                        someField: "someValue",
-                    },
-                },
-            }),
-        );
-
-const myFakeGqlFetch = mockMyQuery(mockGqlFetch());
-
-<GqlRouter fetch={myFakeGqlFetch} defaultContext={{some: "sort of context"}}>
-    <ComponentUnderTest />
-</GqlRouter>
-```
-
-Now, using a compose function, multiple mocks can be setup on the same `mockGqlFetch` instance.
-
-For more details on this and other testing utilities, see the [Wonder Blocks Testing documentation](/docs/testing-overview--page).

package/src/__docs__/exports.abort-inflight-requests.stories.mdx

@@ -1,20 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / abortInflightRequests()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# abortInflightRequests()
-
-```ts
-abortInflightRequests(): void;
-```
-
-Aborts all inflight requests that were started via [`useCachedEffect`](/docs/data-exports-usecachedeffect--page), [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page), or [`fetchTrackedRequests()`](/docs/data-exports-fetchtrackedrequests--page).
-
-NOTE: Full abort signalling is not currently implemented. The effect of this call is to remove any inflight requests from our inflight request tracking such that a new matching request will cause a new fetch to occur rather than sharing any existing one.

package/src/__docs__/exports.data-error.stories.mdx

@@ -1,23 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / DataError"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# DataError
-
-
-```ts
-new DataError(
-    message: string,
-    kind: $Values<typeof DataErrors>,
-    options?: ErrorOptions,
-);
-```
-
-The `DataError` class is a derivation of the Wonder Blocks Core `KindError` (which is itself a derivation of `Error`). It is used by the Wonder Blocks Data framework to encapsulate errors that can occur when using its API. The different kinds of errors supported are defined by the [`DataErrors`](/docs/data-exports-dataerrors--page) export.

package/src/__docs__/exports.data-errors.stories.mdx

@@ -1,23 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / DataErrors"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# DataErrors
-
-This export defines the error taxonomy used by Wonder Blocks Data to describe the errors that can occur. These are for use with [`DataError`](/docs/data-exports-dataerror--page).
-
-| Kind | Description |
-| ---- | ----------- |
-| `DataErrors.Unknown` | The kind of error is not known. |
-| `DataErrors.Internal` | The error is internal to the executing code. |
-| `DataErrors.InvalidInput` | There was a problem with the provided input. |
-| `DataErrors.Network` | A network error occurred. |
-| `DataErrors.Parse` | Response could not be parsed. |
-| `DataErrors.Hydrated` | An error that occurred during SSR and was hydrated from cache |

package/src/__docs__/exports.data.stories.mdx

@@ -1,146 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-import {Data} from "../index.js";
-
-<Meta
-    title="Data / Exports / Data"
-    component={Data}
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# Data
-
-The `Data` component is the frontend piece of our data architecture.
-It describes a data requirement in terms of a handler and an identifier.
-It also has props to govern hydrate behavior as well as loading and client-side
-request behavior.
-
-The handler is responsible for fulfilling the request when asked to do so.
-
-#### Server-side Rendering and Hydration
-
-The Wonder Blocks Data framework uses an in-memory cache for supporting
-server-side rendering (SSR) and hydration.
-
-##### Server-side behavior
-
-###### Cache miss
-
-When the `Data` component does not get data or an error from the cache and it
-is rendering server-side, it tells our request tracking that it wants data, and
-it renders in its `loading` state. It will always render in this state if there
-is no cached response.
-
-###### Cache hit
-
-When the `Data` component gets data or an error from the cache and it is
-rendering server-side, it will render as loaded, with that data or error,
-as it would client-side. In this situation, it does not track the request it
-would have made, as it already has the data and doesn't need to.
-
-
-##### Client-side behavior
-
-###### Cache miss
-
-When the hydration cache does not contain the data, the data will be requested.
-While the request is pending, the data is rendered in the loading state.
-In this example, we use a 3 second delayed promise to simulate the request.
-We start out without any data and so the request is made. Upon receipt of that
-data or an error, we re-render.
-
-```jsx
-import {Body, BodyMonospace} from "@khanacademy/wonder-blocks-typography";
-import {View} from "@khanacademy/wonder-blocks-core";
-import {Data} from "@khanacademy/wonder-blocks-data";
-import {Strut} from "@khanacademy/wonder-blocks-layout";
-import Color from "@khanacademy/wonder-blocks-color";
-import Spacing from "@khanacademy/wonder-blocks-spacing";
-
-const myValidHandler = () => new Promise((resolve, reject) =>
-    setTimeout(() => resolve("I'm DATA from a request"), 3000),
-);
-
-const myInvalidHandler = () => new Promise((resolve, reject) =>
-    setTimeout(() => reject("I'm an ERROR from a request"), 3000),
-);
-
-<View>
-    <View>
-        <Body>This request will succeed and give us data!</Body>
-        <Data handler={myValidHandler} requestId="VALID">
-            {(result) => {
-                if (result.status === "loading") {
-                    return "Loading...";
-                }
-
-                return (
-                    <BodyMonospace>{result.data}</BodyMonospace>
-                );
-            }}
-        </Data>
-    </View>
-    <Strut size={Spacing.small_12} />
-    <View>
-        <Body>This request will go boom and give us an error!</Body>
-        <Data handler={myInvalidHandler} requestId="INVALID">
-            {(result) => {
-                if (result.status === "loading") {
-                    return "Loading...";
-                }
-
-                return (
-                    <BodyMonospace style={{color: Color.red}}>ERROR: {result.error}</BodyMonospace>
-                );
-            }}
-        </Data>
-    </View>
-</View>
-```
-
-###### Cache hit
-
-If the hydration cache already contains data or an error for our request, then
-the `Data` component will render it immediately. The hydration cache is
-populated using the `initializeHydrationCache` method before rendering.
-
-```jsx
-import {Body, BodyMonospace} from "@khanacademy/wonder-blocks-typography";
-import {View} from "@khanacademy/wonder-blocks-core";
-import {Data, initializeHydrationCache} from "@khanacademy/wonder-blocks-data";
-import {Strut} from "@khanacademy/wonder-blocks-layout";
-import Color from "@khanacademy/wonder-blocks-color";
-import Spacing from "@khanacademy/wonder-blocks-spacing";
-
-const myHandler = () => {
-    throw new Error(
-        "If you're seeing this error, the examples are broken and data isn't in the cache that should be.",
-    );
-};
-
-initializeHydrationCache({
-    DATA: {
-        data: "I'm DATA from the hydration cache"
-    },
-});
-
-<View>
-    <View>
-        <Body>This cache has data!</Body>
-        <Data handler={myHandler} requestId="DATA">
-            {(result) => {
-                if (result.status !== "success") {
-                    return "If you see this, the example is broken!";
-                }
-
-                return (
-                    <BodyMonospace>{result.data}</BodyMonospace>
-                );
-            }}
-        </Data>
-    </View>
-</View>
-```

package/src/__docs__/exports.fetch-tracked-requests.stories.mdx

@@ -1,24 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / fetchTrackedRequests()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# fetchTrackedRequests()
-
-```ts
-fetchTrackedRequests(): Promise<ResponseCache>;
-```
-
-When performing server-side rendering (SSR), the data requests that are being made via the [`Data`](/docs/data-exports-data--page) component can be tracked by rendering the React tree inside the [`TrackData`](/docs/data-exports-trackdata--page) component. After this has occurred, the tracked requests can be fulfilled using `fetchTrackedRequests`.
-
-This method returns a promise that resolves to a copy of the data that was cached by fulfilling the tracked requests. In the process, it clears the record of tracked requests so that new requests can be tracked and fulfilled if so required.
-
-The returned copy of the data cache can be used with the [`initializeHydrationCache`](/docs/data-exports-initializehydrationcache--page) method to prepare the data cache before a subsequent render. This is useful on the server to then SSR a more complete result, and again on the client, to rehydrate that result.
-
-More details about server-side rendering with Wonder Blocks Data can be found in the [relevant overview section](/docs/data-server-side-rendering-and-hydration--page).

package/src/__docs__/exports.get-gql-request-id.stories.mdx

@@ -1,24 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / getGqlRequestId()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# getGqlRequestId()
-
-```ts
-function getGqlRequestId<TData, TVariables: {...}>(
-    operation: GqlOperation<TData, TVariables>,
-    variables: ?TVariables,
-    context: GqlContext,
-): string;
-```
-
-The `getGqlRequestId` function generates an identifier based on the operation, variables, and context of a specific GraphQL request. This identifier is guaranteed to be the same for all requests that share the same operation, variables, and context, even if variables and context values are in different orders.
-
-The identifier returned by this function can then be used with our [`useCachedEffect`](/docs/data-exports-usecachedeffect--page), [`useServerEffect`](/docs/data-exports-useservereffect--page), and [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page) hooks as the `requestId` parameter, allowing them to be combined with the fetch operation from the [`useGql`](/docs/data-exports-usegql--page) hook.

package/src/__docs__/exports.gql-error.stories.mdx

@@ -1,23 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / GqlError"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlError
-
-
-```ts
-new GqlError(
-    message: string,
-    kind: $Values<typeof GqlErrors>,
-    options?: ErrorOptions,
-);
-```
-
-The `GqlError` class is a derivation of the Wonder Blocks Core `KindError` (which is itself a derivation of `Error`). It is used by the Wonder Blocks Data GraphQL framework to encapsulate errors that can occur within the GraphQL API. The different kinds of errors supported are defined by the [`GqlErrors`](/docs/data-exports-gqlerrors--page) export.

package/src/__docs__/exports.gql-errors.stories.mdx

@@ -1,20 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / GqlErrors"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlErrors
-
-This export defines the error taxonomy used by Wonder Blocks Data to describe the GraphQL-related errors that can occur with GraphQL requests. These are for use with [`GqlError`](/docs/data-exports-gqlerror--page).
-
-| Kind | Description |
-| ---- | ----------- |
-| `GqlErrors.Unknown` | The type of error is unknown. |
-| `GqlErrors.BadResponse` | Response does not have the correct structure for a GraphQL response. |
-| `GqlErrors.ErrorResult` | A valid GraphQL result with errors field in the payload. |

package/src/__docs__/exports.gql-router.stories.mdx

@@ -1,29 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-import {GqlRouter} from "../index.js";
-
-<Meta
-    title="Data / Exports / GqlRouter"
-    component={GqlRouter}
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlRouter
-
-The `GqlRouter` component is used to define the default context and fetch function for performing GraphQL requests using the Wonder Blocks Data API.
-
-The [`useGql`](/docs/data-exports-usegql--page) (and therefore any hooks or components that use it) requires at least one `GqlRouter` in the component hierarchy above it or it will throw an error.
-
-The `defaultContext` is specific to the needs of your specific implementation, as is the `fetch` function. Currently, a default for the fetch function is not provided by Wonder Blocks Data and should be written to the specification of the server that will fulfill your GraphQL responses. The `fetch` function must conform to the [`GqlFetchFn<>`](/docs/data-types-gqlfetchfn--page) type.
-
-```tsx
-<GqlRouter defaultContext={{a: "1", b: "2"}} fetch={gqlFetchFn}>
-    <div>
-        The code that will ultimately use Wonder Blocks Data-based GraphQL
-        operations goes here.
-    </div>
-</GqlRouter>
-```

package/src/__docs__/exports.has-tracked-requests-to-be-fetched.stories.mdx

@@ -1,20 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / hasTrackedRequestsToBeFetched()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# hasTrackedRequestsToBeFetched()
-
-```ts
-hasTrackedRequestsToBeFetched(): boolean;
-```
-
-When performing server-side rendering (SSR), any requests that have been tracked will cause this method to return `true`. Once [`fetchTrackedRequests`](/docs/data-exports-fetchtrackedrequests--page) has been called and the promise is settled, this method will return `false` to indicate that there are no more pending requests.
-
-More details about server-side rendering with Wonder Blocks Data can be found in the [relevant overview section](/docs/data-server-side-rendering-and-hydration--page).