npm - @khanacademy/wonder-blocks-data - Versions diffs - 10.1.0 → 10.1.2 - Mend

@khanacademy/wonder-blocks-data 10.1.0 → 10.1.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (180) hide show

package/src/__docs__/exports.status.stories.mdx DELETED Viewed

@@ -1,31 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-<Meta
-    title="Data / Exports / Status"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-# Status
-Provides a helper API for creating [`Result<TData>`](/docs/data-types-result--page) instances with specific statuses.
-## loading()
-`Status.loading()` creates a result with the `"loading"` status.
-## aborted()
-`Status.aborted()` creates a result with the `"aborted"` status.
-## success()
-`Status.success()` creates a result with the `"success"` status and the given data.
-## error()
-`Status.error()` creates a result with the `"error"` status and the given error.

package/src/__docs__/exports.track-data.stories.mdx DELETED Viewed

@@ -1,209 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-import {TrackData} from "../index.js";
-<Meta
-    title="Data / Exports / TrackData"
-    component={TrackData}
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-# TrackData
-The `TrackData` component is a server-side only component. It should be used as
-a parent to the components whose data requests you want to fulfill during
-server-side rendering.
-#### Client-side behavior
-If used outside of server-side mode (as set using `Server.setServerSide`), this
-component will throw, as demonstrated below.
-```jsx
-import {Body, BodyMonospace} from "@khanacademy/wonder-blocks-typography";
-import {Server, View} from "@khanacademy/wonder-blocks-core";
-import {TrackData} from "@khanacademy/wonder-blocks-data";
-class ErrorBoundary extends React.Component {
-    constructor(props) {
-        super(props);
-        this.state = {};
-    }
-    static getDerivedStateFromError(error) {
-        return {error: error.message};
-    }
-    render() {
-        if (typeof jest !== "undefined") {
-            /**
-             * The snapshot test just sees the error getting thrown, not the
-             * awesome error boundary, so we have to hack around it to keep
-             * this live example, but not get test failures.
-             */
-            return "Sorry, no snapshot for you";
-        }
-        if (this.state.error) {
-            return (
-                <View>
-                    {this.state.error}
-                </View>
-            );
-        }
-        return this.props.children;
-    }
-}
-<ErrorBoundary>
-    <View>
-        <TrackData>
-            <Body>This only renders if we're in server-side mode and the page hot reloaded</Body>
-        </TrackData>
-    </View>
-</ErrorBoundary>
-```
-#### Server-side behavior
-When used server-side, this component tracks any data requests made through
-the `Data` component during a render cycle. This data can then be obtained
-using the `fetchTrackedRequests` method. The data can then be used in an
-additional render cycle to render with that data.
-```jsx
-import {Body, BodyMonospace} from "@khanacademy/wonder-blocks-typography";
-import {Strut} from "@khanacademy/wonder-blocks-layout";
-import Spacing from "@khanacademy/wonder-blocks-spacing";
-import Button from "@khanacademy/wonder-blocks-button";
-import {Server, View} from "@khanacademy/wonder-blocks-core";
-import {Data, TrackData, fetchTrackedRequests} from "@khanacademy/wonder-blocks-data";
-const myPretendHandler = () => new Promise((resolve, reject) =>
-    setTimeout(() => resolve("DATA!"), 3000),
-);
-class Example extends React.Component {
-    constructor() {
-        super();
-        /**
-         * For this demonstration, we need to hack the return of isServerSide solely
-         * for the scope of this component.
-         */
-        this.state = {};
-    }
-    static getDerivedStateFromError(error) {
-        return {error};
-    }
-    componentDidMount() {
-        this._mounted = true;
-    }
-    componentWillUnmount() {
-        this._mounted = false;
-    }
-    setClientMode() {
-        window.location.reload();
-    }
-    setServerMode() {
-        Server.setServerSide();
-        this.setState({refresh: Date.now(), error: null});
-    };
-    _renderErrorOrContent() {
-        if (typeof jest !== "undefined") {
-            /**
-             * The snapshot test just sees the error getting thrown, not the
-             * awesome error boundary, so we have to hack around it to keep
-             * this live example, but not get test failures.
-             */
-            return "Sorry, no snapshot for you";
-        }
-        if (this.state.error) {
-            return (
-                <React.Fragment>
-                    <Strut size={Spacing.small_12} />
-                    <Body>We can't show you anything useful in client-side mode</Body>
-                </React.Fragment>
-            );
-        }
-        const data = this.state.data
-            ? JSON.stringify(this.state.data, undefined, "  ")
-            : "Data requested...";
-        return (
-            <React.Fragment>
-                <Strut size={Spacing.small_12} />
-                <TrackData>
-                    <Data handler={myPretendHandler} requestId="TRACK_DATA_EXAMPLE">
-                        {(result) => (
-                            <View>
-                                <BodyMonospace>{`Loading: ${result.status === "loading"}`}</BodyMonospace>
-                                <BodyMonospace>{`Data: ${JSON.stringify(result.data)}`}</BodyMonospace>
-                            </View>
-                        )}
-                    </Data>
-                </TrackData>
-                <Strut size={Spacing.small_12} />
-                <View>
-                    <Body>
-                        The above components requested data, but we're server-side,
-                        so all that happened is we tracked the request.
-                        In this example, we've also called `fetchTrackedRequests`
-                        to fetch that tracked data.
-                    </Body>
-                    <Strut size={Spacing.small_12} />
-                    <Body>
-                        In about 3 seconds, it will appear below. Notice that
-                        when it does, the above still doesn't update. That's
-                        because during SSR, the data is not updated in the
-                        rendered tree.
-                    </Body>
-                    <Strut size={Spacing.small_12} />
-                    <BodyMonospace>{data}</BodyMonospace>
-                </View>
-            </React.Fragment>
-        );
-    }
-    render() {
-        try {
-            return (
-                <View key={this.state.refresh}>
-                    {Server.isServerSide()
-                        ? (
-                            <React.Fragment>
-                                <Button kind={"secondary"} onClick={() => this.setClientMode()}>Back to Client-side Mode (reloads page)</Button>
-                                <Strut size={Spacing.small_12} />
-                                <Button kind={"secondary"} onClick={() => this.setServerMode()}>Re-mount</Button>
-                            </React.Fragment>
-                        ) : (
-                            <Button kind={"primary"} onClick={() => this.setServerMode()}>Enable Server-side Mode</Button>
-                        )
-                    }
-                    {this._renderErrorOrContent()}
-                </View>
-            );
-        } finally {
-            if (!this.state.data && Server.isServerSide()) {
-                setTimeout(() => fetchTrackedRequests().then((data) => {
-                    if (this._mounted) {
-                        this.setState({data});
-                    }
-                }), 0);
-            }
-        }
-    }
-}
-<Example />
-```

package/src/__docs__/exports.use-cached-effect.stories.mdx DELETED Viewed

@@ -1,44 +0,0 @@
-import {Meta} from "@storybook/addon-docs";
-<Meta
-    title="Data / Exports / useCachedEffect()"
-    parameters={{
-        chromatic: {
-            disableSnapshot: true,
-        },
-    }}
-/>
-# useCachedEffect()
-```ts
-function useCachedEffect<TData: ValidCacheData>(
-    requestId: string,
-    handler: () => Promise<TData>,
-    options?: CachedEffectOptions<TData>,
-): [Result<TData>, () => void];
-```
-This hook invokes the given handler and caches the result using the [`useSharedCache`](/docs/data-exports-usesharedcache--page) hook. The `requestId` is used to both identify inflight requests that can be shared, and to identify the cached value to use.
-The hook returns an array containing the current state of the request, and a function that can be used to `refetch` that request on demand. Calling `refetch` while an inflight request is in progress for the given `requestId` will be a no-op.
-The behavior of the hook can be modified with the options.
-```ts
-type CachedEffectOptions<TData: ValidCacheData> = {|
-    skip?: boolean,
-    retainResultOnChange?: boolean,
-    onResultChanged?: (result: Result<TData>) => void,
-    scope?: string,
-    fetchPolicy?: FetchPolicy,
-|};
-```
-| Option | Default | Description |
-| ------ | ------- | ----------- |
-| `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. |
-| `fetchPolicy` | [`FetchPolicy`](/docs/data-types-fetchpolicy--page) | Fetch policy to use when fetching the data. Defaults to `FetchPolicy.CacheBeforeNetwork`. |

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

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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.