@khanacademy/wonder-blocks-data 10.0.5 → 10.1.1

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

@@ -1,41 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / useGql()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# useGql()
-
-```ts
-type FetchFn = <TData, TVariables: {...}>(
-    operation: GqlOperation<TData, TVariables>,
-    options?: GqlFetchOptions<TVariables, TContext>,
-) => Promise<TData>;
-
-function useGql<TContext: GqlContext>(
-    context: Partial<TContext> = ({}: $Shape<TContext>),
-): FetchFn;
-```
-
-The `useGql` hook requires that the calling component has been rendered with a [`GqlRouter`](/docs/data-exports-gqlrouter--page) as an ancestor component since it relies on the default context and fetch operation that is specified therein.
-
-The `useGql` hook can take a partial context value which will be combined with the default context to create the context used for a specific request.
-
-The return value of `useGql` is a fetch function that can be used to invoke a GraphQL request. It takes as arguments the [`GqlOperation`](/docs/data-types-gqloperation--page) operation to be performed and some options (which, by their nature, are optional). These options can be used to provide variables for the operation as well as additional customization of the context.
-
-The result of calling the function returned by `useGql` is a promise of the data that the request will return. This is compatible with the [`useServerEffect`](/docs/data-exports-useservereffect--page), [`useCachedEffect`](/docs/data-exports-usecachedeffect--page),  and [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page) hooks, allowing a variety of scenarios to be easily constructed.
-
-Use [`getGqlRequestId`](/docs/data-exports-getgqlrequestid--page) to get a request ID that can be used with these hooks.
-
-## Context Merging
-
-Context overrides are combined such that any values that are explicitly or implicitly `undefined` on the partial context will be ignored. Any values that are explicitly `null` on the partial context will be removed from the merged context. The order of precedence is as follows:
-
- 1. Values from the fetch partial context, then,
- 2. Values from the `useGql` partial context, then,
- 3. Values from the default context.

package/src/__docs__/exports.use-hydratable-effect.stories.mdx

@@ -1,43 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / useHydratableEffect()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# useHydratableEffect()
-
-```ts
-function useHydratableEffect<TData: ValidCacheData>(
-    requestId: string,
-    handler: () => Promise<TData>,
-    options?: HydratableEffectOptions<TData>,
-): Result<TData>;
-```
-
-This hook combines [`useServerEffect`](/docs/data-exports-useservereffect--page) and [`useCachedEffect`](/docs/data-exports-usecachedeffect--page) to form an effect that can execute on the server and hydrate on the client.
-
-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).
-
-
-```ts
-type HydratableEffectOptions<TData: ValidCacheData> = {|
-    clientBehavior?: WhenClientSide,
-    skip?: boolean,
-    retainResultOnChange?: boolean,
-    onResultChanged?: (result: Result<TData>) => void,
-    scope?: string,
-|};
-```
-
-| Option | Default | Description |
-| ------ | ------- | ----------- |
-| `clientBehavior` | [`WhenClientSide.ExecuteWhenNoSuccessResult`](/docs/data-exports-whenclientside--page#whenclientsideexecutewhennosuccessresult) | How the hook should behave when rendering client-side for the first time. This controls the hydration and execution of the effect on the client. Changing this value after the initial render is inert. For more information on other behaviors, see [`WhenClientSide`](/docs/data-exports-whenclientside--page). |
-| `skip` | `false` | When `true`, the effect will not be executed; otherwise, the effect will be executed.  If this is set to `true` while the effect is still pending, the pending effect will be cancelled. |
-| `retainResultOnChange` | `false` | When `true`, the effect will not reset the result to the loading status while executing if the requestId changes, instead, returning the existing result from before the change; otherwise, the result will be set to loading status.  If the status is loading when the changes are made, it will remain as loading; old pending effects are discarded on changes and as such this value has no effect in that case.|
-| `onResultChanged` | `undefined` | Callback that is invoked if the result for the given hook has changed. When defined, the hook will invoke this callback whenever it has reason to change the result and will not otherwise affect component rendering directly. When not defined, the hook will ensure the component re-renders to pick up the latest result. |
-| `scope` | `"useCachedEffect"` | Scope to use with the shared cache. When specified, the given scope will be used to isolate this hook's cached results. Otherwise, the default scope will be used. Changing this value after the first call is not supported. |

package/src/__docs__/exports.use-server-effect.stories.mdx

@@ -1,50 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / useServerEffect()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# useServerEffect()
-
-```ts
-function useServerEffect<TData: ValidCacheData>(
-    requestId: string,
-    handler: () => Promise<TData>,
-    options?: ServerEffectOptions,
-): ?Result<TData>;
-```
-
-The `useServerEffect` hook is an integral part of server-side rendering. It has different behavior depending on whether it is running on the server (and in what context) or the client.
-
-```ts
-type ServerEffectOptions = {|
-    skip?: boolean,
-    hydrate?: boolean,
-|};
-```
-
-| Option | Default | Description |
-| ------ | ------- | ----------- |
-| `hydrate` | `true` | When `true`, the result of the effect when fulfilled using Wonder Blocks Data will be stored in the hydration cache for hydrating client-side; otherwise, the result will be stored in the server-side-only cache. |
-| `skip` | `false` | When `true`, the effect will not be tracked for fulfillment; otherwise, the effect will be tracked for fulfillment. |
-
-## Server-side behavior
-
-First, this hook checks the server-side rendering cache for the request identifier; if it finds a cached value, it will return that.
-
-If there is no cached value, it will return a "loading" state. In addition, if the current rendering component has a [`TrackData`](/docs/data-exports-trackdata--page) ancestor, `useServerEffect` will register the request for fulfillment.
-
-This then allows that pending request to be fulfilled with [`fetchTrackedRequests`](/docs/data-exports-fetchtrackddatarequests--page), the response to be placed into the cache, and the render to be reexecuted, at which point, this hook will be able to provide that result instead of "loading.
-
-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).
-
-## Client-side behavior
-
-On initial render in the client, this hook will look for a corresponding value in the Wonder Blocks Data hydration cache. If there is one, it will delete it from the hydration cache and return that value.
-
-Otherwise, it will return `null`.

package/src/__docs__/exports.use-shared-cache.stories.mdx

@@ -1,30 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / useSharedCache()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# useSharedCache()
-
-```ts
-function useSharedCache<TValue: ValidCacheData>(
-    id: string,
-    scope: string,
-    initialValue?: ?TValue | (() => ?TValue),
-): [?TValue, CacheValueFn<TValue>];
-```
-
-The `useSharedCache` hook provides access to a shared in-memory cache. This cache is not part of the cache hydrated by Wonder Blocks Data, so [`SharedCache.purgeAll()`](/docs/data-exports-sharedcache--page) must be called between server-side render cycles.
-
-The hook returns a tuple of the currently cached value, or `null` if none is cached, and a function that can be used to set the cached value.
-
-The shared cache is passive and as such does not notify of changes to its contents.
-
-Each cached item is identified by an id and a scope. The scope is used to group items. Whole scopes can be cleared by specifying the specific scope when calling [`SharedCache.purgeScope()`](/docs/data-exports-sharedcache--page).
-
-An optional argument, `initialValue` can be given. This can be either the value to be cached itself or a function that returns the value to be cached  (functions themselves are not valid cachable values). This allows for expensive initialization to only occur when it is necessary.

package/src/__docs__/exports.when-client-side.stories.mdx

@@ -1,33 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Exports / WhenClientSide"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# WhenClientSide
-
-This enumeration is used with [`useHydratableEffect`](/docs/data-exports-usehydratableeffect--page). It defines how the hook should behave when rendering on the client.
-
-## WhenClientSide.DoNotHydrate
-
-The effect will not be hydrated and as such the effect will always be executed on initial render in the client. This is an advanced use-case that you should avoid unless you are certain of what you are doing.
-
-Without hydration support to ensure the data is available for hydration on the client, your server and client rendered pages may differ and the hydration will fail. This option is useful if something else is responsible for data capture and hydration of the action that gets executed. For example, if the action uses Apollo Client to perform the asynchronous action executed by this effect, then that may be also performing hydration responsibilities. However, be cautious; the code that calls `useHydratableEffect` will have to have access to that data on hydration as `useHydratableEffect` will return a "loading" state on initial render, which is not what you will want.
-
-## WhenClientSide.ExecuteWhenNoResult
-
-On initial render in the client, the effect is hydrated from the server-side rendered result. However, it is only executed if there was no server-side render result to hydrate (this can happen if the server-side rendered request was aborted, or if the component is rendering for the first time on the client and was never part of the server-side rendered content).
-
-## WhenClientSide.ExecuteWhenNoSuccessResult
-
-This behavior will hydrate the server-side result, but it will only execute the effect on the client if the hydrated result is not a success result.
-
-## WhenClientSide.AlwaysExecute
-
-When the effect is executed with this behavior, the server-side result will be hydrated and the effect will be executed on the initial client-side render, regardless of the hydrated result status.
-

package/src/__docs__/types.cached-response.stories.mdx

@@ -1,29 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / CachedResponse<>"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# CachedResponse&lt;&gt;
-
-```ts
-type CachedResponse<TData: ValidCacheData> =
-    | {|
-          +error: string,
-          +data?: void,
-      |}
-    | {|
-          +data: TData,
-          +error?: void,
-      |};
-```
-
-`CachedResponse<>` is a special union type that is used to represent the serialized result of a request, which can be used by Wonder Blocks Data to
-hydrate the response.
-
-See the section on [server-side rendering](/docs/data-server-side-rendering-and-hydration--page) for more information.

package/src/__docs__/types.error-options.stories.mdx

@@ -1,21 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / ErrorOptions"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# ErrorOptions
-
-```ts
-type ErrorOptions = {|
-    metadata?: ?Metadata,
-    cause?: ?Error,
-|};
-```
-
-These options allow for the provision of a causal error instance as well as additional metadata that may be useful to the specific error being constructed (such as [`DataError`](/docs/data-exports-dataerror--page) or [`GqlError`](/docs/data-exports-gqlerror--page)).

package/src/__docs__/types.fetch-policy.stories.mdx

@@ -1,44 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / FetchPolicy"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# FetchPolicy
-
-```ts
-export enum FetchPolicy {
-    /**
-     * If the data is in the cache, return that; otherwise, fetch from the server.
-     */
-    CacheBeforeNetwork,
-
-    /**
-     * If the data is in the cache, return that; always fetch from the server
-     * regardless of cache.
-     */
-    CacheAndNetwork,
-
-    /**
-     * If the data is in the cache, return that; otherwise, do nothing.
-     */
-    CacheOnly,
-
-    /**
-     * Ignore any existing cached result; fetch from the server.
-     */
-    NetworkOnly,
-}
-```
-
-The `FetchPolicy` type is used with our request framework to define how a request should be fulfilled with respect to the cache and the network.
-
- * `CacheBeforeNetwork`: If the data is in the cache, return that; otherwise, fetch from the server.
- * `CacheAndNetwork`:  If the data is in the cache, return that; always fetch from the server regardless of cache.
- * `CacheOnly`: If the data is in the cache, return that; otherwise, do nothing.
- * `NetworkOnly`: Ignore any existing cached result; always fetch from the server.

package/src/__docs__/types.gql-context.stories.mdx

@@ -1,20 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / GqlContext"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlContext
-
-```ts
-type GqlContext = {|
-    [key: string]: string,
-|};
-```
-
-`GqlContext` represents the valid range of values for the `context` of a GraphQL query or mutation.

package/src/__docs__/types.gql-fetch-fn.stories.mdx

@@ -1,24 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / GqlFetchFn<>"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlFetchFn&lt;&gt;
-
-```ts
-type GqlFetchFn<TData, TVariables: {...}, TContext: GqlContext> = (
-    operation: GqlOperation<TData, TVariables>,
-    variables: ?TVariables,
-    context: TContext,
-) => Promise<Response>;
-```
-
-The `GqlFetchFn<>` type describes the function that will perform a GraphQL request. A function that fits this signature is configured in Wonder Blocks Data using the [`GqlRouter`](/docs/data-exports-gqlrouter--page) component. The [`useGql`](/docs/data-exports-usegql--page) hook and derivatives are then built on top of this to abstract away complexities, such as converting the `Response` to a valid [`Result<>`](/docs/data-types-result--page) instance, as various use cases see fit.
-
-See the section on [GraphQL](/docs/data-graphql--page) for more information.

package/src/__docs__/types.gql-fetch-options.stories.mdx

@@ -1,24 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / GqlFetchOptions<>"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlFetchOptions&lt;&gt;
-
-```ts
-type GqlFetchOptions<TVariables: {...}, TContext: GqlContext> = {|
-    variables?: TVariables,
-    context?: Partial<TContext>,
-|};
-```
-
-This type describes optional configuration to apply when fulfilling a GraphQL request.
-
-See the section on [GraphQL](/docs/data-graphql--page) for more information.
-

package/src/__docs__/types.gql-operation-type.stories.mdx

@@ -1,24 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / GqlOperationType"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlOperationType
-
-```ts
-type GqlOperationType = "mutation" | "query";
-```
-
-Unlike some GraphQL clients, the Wonder Blocks Data GraphQL support avoids requiring the full GraphQL document node at runtime. This allows the client to be lighter weight and introduces the option for calling code to perform some GraphQL request optimizations at build time, such as formatting the document node as a string and therefore not requiring additional dependencies at runtime.
-
-In order to allow consumers of our GraphQL support to include some validation of the GraphQL document node at runtime (such as ensuring that mutations are not performed in unsupported scenarios), we the type of the operation is included in the operation definition.
-
-This type represents the valid values for that field.
-
-See the section on [GraphQL](/docs/data-graphql--page) for more information.

package/src/__docs__/types.gql-operation.stories.mdx

@@ -1,67 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / GqlOperation<>"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# GqlOperation&lt;&gt;
-
-```ts
-type GqlOperation<
-    TData,
-    TVariables: {...} = Empty,
-> = {
-    type: GqlOperationType,
-    id: string,
-    [key: string]: mixed,
-    ...
-};
-```
-
-The `GqlOperation<>` type provides the Wonder Blocks Data definition of a GraphQL query or mutation. It has two required fields:
-
- * `type`: The type of operation. It can be either `"query"` or `"mutation"`.
- * `id`: The unique identifier of the operation.
-
-Unlike some GraphQL clients, the definition of the operation (the document node, for example) is not required by the Wonder Blocks Data implementation. If a specific use requires that information, the calling code is able to provide it.
-
-Consider the following GraphQL query (using `graphql-tag`):
-
-```ts
-const MyQuery = gql`
-    query myQuery {
-        user {
-            id
-            name
-        }
-    }
-`;
-```
-
-Rather than using the full `DocumentNode` at runtime, one could envisage a build step that converts it to a `GqlOperation<>` at compile time by parsing the `DocumentNode` to determine the operation type and extract the name of the operation. If the actual definition is needed for sending to the server in the request, this can be obtained from `graphql/language/printer`. This would then reduce the dependencies needed to perform GraphQL operations at runtime.
-
-The resulting `GqlOperation<>` would look like this:
-
-```ts
-{
-    type: "query",
-    id: "myQuery",
-}
-```
-
-Or, if say, the query definition were needed (for example, Apollo will send requests with the `query` field):
-
-```ts
-{
-    type: "query",
-    id: "myQuery",
-    query: "query myQuery { user { id name } }",
-}
-```
-
-See the section on [GraphQL](/docs/data-graphql--page) for more information.

package/src/__docs__/types.raw-scoped-cache.stories.mdx

@@ -1,27 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / RawScopedCache"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# RawScopedCache
-
-```ts
-type RawScopedCache = {
-    [scope: string]: {
-        [id: string]: ValidCacheData,
-        ...
-    },
-    ...
-};
-
-```
-
-`RawScopedCache` describes a cache that has distinct scoped sections in its raw object form. This is the representation of the caches used internally by Wonder Blocks Data to support the scoping of requests when using hooks such as [`useSharedCache`](/docs/data-exports-use-shared-cache--page), [`useCachedEffect`](/docs/data-exports-use-cached-effect--page), and [`useHydratableEffect`](/docs/data-exports-use-hydratable-effect--page).
-
-See the section on [server-side rendering](/docs/data-server-side-rendering-and-hydration--page) for more information.

package/src/__docs__/types.response-cache.stories.mdx

@@ -1,33 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / ResponseCache"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# ResponseCache
-
-```ts
-type ResponseCache = {
-    [key: string]: CachedResponse<any>,
-    ...
-};
-```
-
-`ResponseCache` describes the serialized cache that is used to hydrate responses. An example of a valid `ResponseCache` instance is shown below. Generally, you would not generate this object directly, but rather use the returned data from [`fetchTrackedRequests`](/docs/data-exports-fetchtrackedrequests--page).
-
-```ts
-const responseCache: ResponseCache = {
-    DATA_ID_1: {error: "It go 💥boom 😢"},
-    DATA_ID_2: {data: ["array", "of", "data"]},
-    DATA_ID_3: {data: {some: "data"}},
-};
-```
-
-In this example, the cache contains data retrieved for three different requests.
-
-Each entry in the cache is of type [`CachedResponse`](/docs/data-types-cachedresponse--page). See the section on [server-side rendering](/docs/data-server-side-rendering-and-hydration--page) for more information.

package/src/__docs__/types.result.stories.mdx

@@ -1,39 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-
-<Meta
-    title="Data / Types / Result<>"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-
-# Result&lt;&gt;
-
-```ts
-type Result<TData: ValidCacheData> =
-    | {|
-          status: "loading",
-      |}
-    | {|
-          status: "success",
-          data: TData,
-      |}
-    | {|
-          status: "error",
-          error: Error,
-      |}
-    | {|
-          status: "aborted",
-      |};
-```
-
-The `Result<>` type is used to describe the result of an asynchronous operation. It is the primary type used by hooks and components in Wonder Blocks Data to convey the status of asynchronous tasks.
-
-There are four states represented by the `Result<>` type:
-
- * `loading`: The operation is in pending.
- * `success`: The operation completed successfully.
- * `error`: The operation failed.
- * `aborted`: The operation was aborted.