Convert ###'s and ####'s to h3/h4's

This is a workaround until gatsbyjs/gatsby#16344
is ready.

docs/source/api/react-components.mdx

@@ -16,13 +16,13 @@ Npm: [`@apollo/react-components`](https://www.npmjs.com/package/@apollo/react-co
 
 ## `Query`
 
-### Props
+<h3>Props</h3>
 
 The `Query` component accepts the following props. `query` is **required**.
 
 <QueryOptions />
 
-### Render prop function
+<h3>Render prop function</h3>
 
 The render prop function that you pass to the `children` prop of `Query` is called with an object (`QueryResult`) that has the following properties. This object contains your query result, plus some helpful functions for refetching, dynamic polling, and pagination.
 
@@ -34,21 +34,21 @@ The Mutation component accepts the following props. Only `mutation` is **require
 
 <MutationOptions />
 
-### Render prop function
+<h3>Render prop function</h3>
 
 The render prop function that you pass to the `children` prop of `Mutation` is called with the `mutate` function and an object with the mutation result. The `mutate` function is how you trigger the mutation from your UI. The object contains your mutation result, plus loading and error state.
 
 <MutationResult />
 
 ## `Subscription`
 
-### Props
+<h3>Props</h3>
 
 The Subscription component accepts the following props. Only `subscription` is **required**.
 
 <SubscriptionOptions />
 
-### Render prop function
+<h3>Render prop function</h3>
 
 The render prop function that you pass to the `children` prop of `Subscription` is called with an object that has the following properties.
 

docs/source/essentials/get-started.mdx

@@ -167,7 +167,7 @@ If you'd like to explore further, here are more versions of the example app feat
 
 In our example app, we used Apollo Boost in order to quickly set up Apollo Client. While your GraphQL server endpoint is the only configuration option you need to get started, there are some other options we've included so you can quickly implement features like local state management, authentication, and error handling.
 
-### What's included
+<h3>What's included</h3>
 
 Apollo Boost includes some packages that we think are essential to developing with Apollo Client. Here's what's included:
 
@@ -178,7 +178,7 @@ Apollo Boost includes some packages that we think are essential to developing wi
 
 The awesome thing about Apollo Boost is that you don't have to set any of this up yourself! Just specify a few options if you'd like to use these features and we'll take care of the rest.
 
-### Configuration options
+<h3>Configuration options</h3>
 
 Here are the options you can pass to the `ApolloClient` exported from `apollo-boost`. All of them are optional.
 

docs/source/essentials/local-state.mdx

@@ -19,7 +19,7 @@ Please note that this documentation is intended to be used to familiarize yourse
 
 There are two main ways to perform local state mutations. The first way is to directly write to the cache by calling `cache.writeData`. Direct writes are great for one-off mutations that don't depend on the data that's currently in the cache, such as writing a single value. The second way is by leveraging the `useMutation` Hook with a GraphQL mutation that calls a local client-side resolver. We recommend using resolvers if your mutation depends on existing values in the cache, such as adding an item to a list or toggling a boolean.
 
-### Direct writes
+<h3>Direct writes</h3>
 
 Direct writes to the cache do not require a GraphQL mutation or a resolver function. They leverage your Apollo Client instance directly by accessing the `client` property returned from the `useApolloClient` Hook, made available in the `useQuery` Hook result, or within the render prop function of the `ApolloConsumer` component. We recommend using this strategy for simple writes, such as writing a string, or one-off writes. It's important to note that direct writes are not implemented as GraphQL mutations under the hood, so you shouldn't include them in your schema. They also do not validate that the data you're writing to the cache is in the shape of valid GraphQL data. If either of these features are important to you, you should opt to use a local resolver instead.
 
@@ -137,7 +137,7 @@ const FilterLink = ({ filter, children }) => (
 
 You'll notice in our query that we have a `@client` directive next to our `visibilityFilter` field. This tells Apollo Client to fetch the field data locally (either from the cache or using a local resolver), instead of sending it to our GraphQL server. Once you call `client.writeData`, the query result on the render prop function will automatically update. All cache writes and reads are synchronous, so you don't have to worry about loading state.
 
-### Local resolvers
+<h3>Local resolvers</h3>
 
 If you'd like to implement your local state update as a GraphQL mutation, then you'll need to specify a function in your local resolver map. The resolver map is an object with resolver functions for each GraphQL object type. To visualize how this all lines up, it's useful to think of a GraphQL query or mutation as a tree of function calls for each field. These function calls resolve to data or another function call. So when a GraphQL query is run through Apollo Client, it looks for a way to essentially run functions for each field in the query. When it finds an `@client` directive on a field, it turns to its internal resolver map looking for a function it can run for that field.
 
@@ -330,7 +330,7 @@ Here we create our GraphQL query and add `@client` directives to `todos` and `vi
 
 > ⚠️ Since the above query runs as soon as the component is mounted, what do we do if there are no todos in the cache or there aren't any local resolvers defined to help calculate `todos`? We need to write an initial state to the cache before the query is run to prevent it from erroring out. Refer to the [Initializing the cache](#initializing-the-cache) section below for more information.
 
-### Initializing the cache
+<h3>Initializing the cache</h3>
 
 Often, you'll need to write an initial state to the cache so any components querying data before a mutation is triggered don't error out. To accomplish this, you can use `cache.writeData` to prep the cache with initial values. The shape of your initial state should match how you plan to query it in your application.
 
@@ -382,7 +382,7 @@ cache.writeData({ data });
 client.onResetStore(() => cache.writeData({ data }));
 ```
 
-### Local data query flow
+<h3>Local data query flow</h3>
 
 When a query containing `@client` directives is executed, Apollo Client runs through a few sequential steps to try to find a result for the `@client` field. Let's use the following query to walk through the local data look up flow:
 
@@ -410,7 +410,7 @@ Let's look at both of these steps more closely.
 - Resolving `@client` data with the help of local resolvers (step 1 above) is explained in [Handling `@client` fields with resolvers][].
 - Loading `@client` data from the cache (step 2 above) is explained in [Handling `@client` fields with the cache](#handling-client-fields-with-the-cache).
 
-### Handling `@client` fields with resolvers
+<h3>Handling `@client` fields with resolvers</h3>
 
 Local resolvers are very similar to remote resolvers. Instead of sending your GraphQL query to a remote GraphQL endpoint, which then runs resolver functions against your query to populate and return a result set, Apollo Client runs locally defined resolver functions against any fields marked with the `@client` directive. Let's look at an example:
 
@@ -482,7 +482,7 @@ Setting resolvers through `ApolloClient`'s constructor `resolvers` parameter, or
 
 Just like resolvers on the server, local resolvers are extremely flexible. They can be used to perform any kind of local computation you want, before returning a result for the specified field. You can manually query (or write to) the cache in different ways, call other helper utilities or libraries to prep/validate/clean data, track statistics, call into other data stores to prep a result, etc.
 
-#### Integrating `@client` into remote queries
+<h4>Integrating `@client` into remote queries</h4>
 
 While Apollo Client’s local state handling features can be used to work with local state exclusively, most Apollo based applications are built to work with remote data sources. To address this, Apollo Client supports mixing `@client` based local resolvers with remote queries, as well as using `@client` based fields as arguments to remote queries, in the same request.
 
@@ -563,7 +563,7 @@ const client = new ApolloClient({
 
 Apollo Client supports the merging of local `@client` results and remote results for Queries, Mutations and Subscriptions.
 
-#### Async local resolvers
+<h4>Async local resolvers</h4>
 
 Apollo Client supports asynchronous local resolver functions. These functions can either be `async` functions or ordinary functions that return a `Promise`. Asynchronous resolvers are useful when they need to return data from an asynchronous API.
 
@@ -627,7 +627,7 @@ const GET_PHOTOS = gql`
 `;
 ```
 
-### Handling `@client` fields with the cache
+<h3>Handling `@client` fields with the cache</h3>
 
 As outlined in [Handling `@client` fields with resolvers][], `@client` fields can be resolved with the help of local resolver functions. However, it's important to note that local resolvers are not always required when using an `@client` directive. Fields marked with `@client` can still be resolved locally, by pulling matching values out of the cache directly. For example:
 
@@ -733,7 +733,7 @@ In the above example, we first prep the cache using `cache.writeData` to store a
 
 Pulling `@client` field values directly out of the cache isn't quite as flexible as local resolver functions, since local resolvers can perform extra computations before returning a result. Depending on your application's needs however, loading `@client` fields directly from the cache might be a simpler option. Apollo Client doesn't restrict combining both approaches, so feel free to mix and match. If the need arises, you can pull some `@client` values from the cache, and resolve others with local resolvers, all in the same query.
 
-### Working with fetch policies
+<h3>Working with fetch policies</h3>
 
 Before Apollo Client executes a query, one of the first things it does is check to see which [`fetchPolicy`](/api/apollo-client/#ApolloClient.query) it has been configured to use. It does this so it knows where it should attempt to resolve the query from first, either the cache or the network. When running a query, Apollo Client treats `@client` based local resolvers just like it does remote resolvers, in that it will adhere to its defined `fetchPolicy` to know where to attempt to pull data from first. When working with local resolvers, it's important to understand how fetch policies impact the running of resolver functions, since by default local resolver functions are not run on every request. This is because the result of running a local resolver is cached with the rest of the query result, and pulled from the cache on the next request. Let's look at an example:
 
@@ -862,7 +862,7 @@ When the `GET_LAUNCH_DETAILS` query is run a second time, again since we're usin
 
 In a lot of situations treating local resolvers just like remote resolvers, by having them adhere to the same `fetchPolicy`, makes a lot of sense. Once you have the data you're looking for, which might have been fetched remotely or calculated using a local resolver, you can cache it and avoid recalculating/re-fetching it again on a subsequent request. But what if you're using local resolvers to run calculations that you need fired on every request? There are a few different ways this can be handled. You can switch your query to use a `fetchPolicy` that forces your entire query to run on each request, like `no-cache` or `network-only`. This will make sure your local resolvers fire on every request, but it will also make sure your network based query components fire on every request. Depending on your use case this might be okay, but what if you want the network parts of your query to leverage the cache, and just want your `@client` parts to run on every request? We'll cover a more flexible option for this in the [Forcing resolvers with `@client(always: true)`](#forcing-resolvers-with-clientalways-true) section.
 
-### Forcing resolvers with `@client(always: true)`
+<h3>Forcing resolvers with `@client(always: true)`</h3>
 
 Apollo Client leverages its cache to help reduce the network overhead required when constantly making requests for the same data. By default, `@client` based fields leverage the cache in the exact same manner as remote fields. After a local resolver is run, its result is cached alongside any remote results. This way the next time a query is fired that can find its results in the cache, those results are used, and any associated local resolvers are not fired again (until the data is either removed from the cache or the query is updated to use a `no-cache` or `network-only` `fetchPolicy`).
 
@@ -899,7 +899,7 @@ The `isLoggedIn` resolver above is checking to see if an authentication token ex
 
 While `@client(always: true)` ensures that a local resolver is always fired, it's important to note that if a query is using a `fetchPolicy` that leverages the cache first (`cache-first`, `cache-and-network`, `cache-only`), the query is still attempted to be resolved from the cache first, before the local resolver is fired.    This happens because `@client(always: true)` use could be mixed with normal `@client` use in the same query, which means we want part of the query to adhere to the defined `fetchPolicy`. The benefit of this is that anything that can be loaded from the cache first is made available to your `@client(always: true)` resolver function, as its [first parameter](#local-resolvers). So even though you've used `@client(always: true)` to identify that you want to always run a specific resolver, within that resolver you can look at the loaded cache values for the query, and decide if you want to proceed with running the resolver.
 
-### Using `@client` fields as variables
+<h3>Using `@client` fields as variables</h3>
 
 Apollo Client provides a way to use an `@client` field result as a variable for a selection set or field, in the same operation. So instead of running an `@client` based query first, getting the local result, then running a second query using the loaded local result as a variable, everything can be handled in one request. This is achieved by combining the `@client` directive with the `@export(as: "variableName")` directive:
 
@@ -1024,7 +1024,7 @@ So here the `currentAuthorId` is loaded from the cache, then passed into the `po
 
 When you're using Apollo Client to work with local state, your Apollo cache becomes the single source of truth for all of your local and remote data. The [Apollo cache API](/advanced/caching/) has several methods that can assist you with updating and retrieving data. Let's walk through the most relevant methods, and explore some common use cases for each one.
 
-### writeData
+<h3>writeData</h3>
 
 The easiest way to update the cache is with `cache.writeData`, which allows you to write data directly to the cache without passing in a query. Here's how you use it in your resolver map for a simple update:
 
@@ -1068,7 +1068,7 @@ const client = new ApolloClient({
 
 `cache.writeData` should cover most of your needs; however, there are some cases where the data you're writing to the cache depends on the data that's already there. In that scenario, you should use `readQuery` or `readFragment`, which allows you to pass in a query or a fragment to read data from the cache. If you'd like to validate the shape of your data that you're writing to the cache, use `writeQuery` or `writeFragment`. We'll explain some of those use cases below.
 
-### writeQuery and readQuery
+<h3>writeQuery and readQuery</h3>
 
 Sometimes, the data you're writing to the cache depends on data that's already in the cache; for example, you're adding an item to a list or setting a property based on an existing property value. In that case, you should use `cache.readQuery` to pass in a query and read a value from the cache before you write any data. Let's look at an example where we add a todo to a list:
 
@@ -1119,7 +1119,7 @@ In order to add our todo to the list, we need the todos that are currently in th
 
 To write the data to the cache, you can use either `cache.writeQuery` or `cache.writeData`. The only difference between the two is that `cache.writeQuery` requires that you pass in a query to validate that the shape of the data you're writing to the cache is the same as the shape of the data required by the query. Under the hood, `cache.writeData` automatically constructs a query from the `data` object you pass in and calls `cache.writeQuery`.
 
-### writeFragment and readFragment
+<h3>writeFragment and readFragment</h3>
 
 `cache.readFragment` is similar to `cache.readQuery` except you pass in a fragment. This allows for greater flexibility because you can read from any entry in the cache as long as you have its cache key. In contrast, `cache.readQuery` only lets you read from the root of your cache.
 
@@ -1195,7 +1195,7 @@ If you open up Apollo Client Devtools and click on the `GraphiQL` tab, you'll be
 
 ## Advanced
 
-### Code splitting
+<h3>Code splitting</h3>
 
 Depending on the complexity and size of your local resolvers, you might not always want to define them up front, when you create your initial `ApolloClient` instance. If you have local resolvers that are only needed in a specific part of your application, you can leverage Apollo Client's [`addResolvers` and `setResolvers`](#methods) functions to adjust your resolver map at any point. This can be really useful when leveraging techniques like route based code-splitting, using something like [`react-loadable`](https://github.com/jamiebuilds/react-loadable).
 
@@ -1395,9 +1395,9 @@ Managing your local data with Apollo Client can help simplify your state managem
 
 Apollo Client local state handling is baked in, so you don't have to install anything extra. Local state management can be configured during `ApolloClient` instantiation (via the `ApolloClient` constructor) or by using the `ApolloClient` local state API. Data in the cache can be managed through the `ApolloCache` API.
 
-### ApolloClient
+<h3>ApolloClient</h3>
 
-#### Constructor
+<h4>Constructor</h4>
 
 ```js
 import { ApolloClient } from 'apollo-client';
@@ -1417,7 +1417,7 @@ const client = new ApolloClient({
 
 None of these options are required. If you don't specify anything, you will still be able to use the `@client` directive to query the Apollo Client cache.
 
-#### Methods
+<h4>Methods</h4>
 
 ```js
 import { ApolloClient } from 'apollo-client';
@@ -1459,9 +1459,9 @@ type FragmentMatcher = (
 ) => boolean;
 ```
 
-### ApolloCache
+<h3>ApolloCache</h3>
 
-#### Methods
+<h4>Methods</h4>
 
 ```js
 import { InMemoryCache } from 'apollo-cache-inmemory';

docs/source/features/error-handling.mdx

@@ -88,7 +88,7 @@ Any errors reported will come under an `error` prop along side the data returned
 
 When using Apollo Link, the ability to handle network errors is way more powerful. The best way to do this is to use the `apollo-link-error` to catch and handle server errors, network errors, and GraphQL errors. If you would like to combine with other links, see [composing links](https://www.apollographql.com/docs/link/composition).
 
-#### Usage
+<h4>Usage</h4>
 
 ```js
 import { onError } from "apollo-link-error";
@@ -105,7 +105,7 @@ const link = onError(({ graphQLErrors, networkError }) => {
 });
 ```
 
-#### Options
+<h4>Options</h4>
 
 Error Link takes a function that is called in the event of an error. This function is called with an object containing the following keys:
 
@@ -114,7 +114,7 @@ Error Link takes a function that is called in the event of an error. This functi
 - `graphQLErrors`: An array of errors from the GraphQL endpoint
 - `networkError`: any error during the link execution or server response
 
-#### Ignoring errors
+<h4>Ignoring errors</h4>
 
 If you want to conditionally ignore errors, you can set `response.errors = null;` within the error handler: