Blocking Fallback for getStaticPaths–New Next.js 10 feature
Tags: react, nextjs, vercel
Published: 2020-11-01 10:22:58

# Table Of Contents
  * [Why was `fallback: 'blocking'` introduced?](#chapter-1)
  * [How does `fallback: 'blocking'` work?](#chapter-2)
  * [When (not) to use `fallback: 'blocking'`?](#chapter-3)

<a name="chapter-1"></a>
<br />
# Why was `fallback: 'blocking'` introduced? 🤔🤔

When Vercel released the `9.3` version of their popular Next.js framework, two brand new data fetching methods were introduced: `getStaticProps` and `getServerSideProps`.

If you want to use `getStaticProps` with, for example, a detail page of a product (`pages/products/[id].js`) you use `getStaticPaths` along with `getStaticProps` to define which product IDs you want to generate the page for.

If, however, you have a large e-commerce site with 10,000 products, you wouldn't want to return the IDs of *all* products from the `getStaticPaths` as building 10,000 pages would take ages.

Instead, you might just return the IDs of the most popular products and use `fallback: true` in `getStaticPaths`.

If you then a product page of some obscure product that's not frequently visited (e. g. `/products/43284`) for the first time, you'd be presented with a loading screen 💻 before the page gets generated (and the product data is fetched in `getStaticProps`). 

(If you don't want to fetch other products than you specified, use `fallback: false` and Next.js will return a 404 🛑 for those pages.)

Every subsequent visit will serve the page statically 🚀 as the page is built (and cached) on the first visit.

However, having to use the loading indicator during the first visit has some issues:

- Some `og:*` crawlers (Facebook, Twitter, LinkedIn, ...) don't support JS and thus fail to fetch correct `og:*` tags for `fallback: true` pages 
- AMP pages 📲 don't work correctly with `fallback: true` as they get stuck loading. ([https://github.com/vercel/next.js/issues/14256](https://github.com/vercel/next.js/issues/14256))

Therefore, the Next.js team introduced a third option for the `fallback` field: `'blocking'`.

(See [https://github.com/vercel/next.js/issues/15637](https://github.com/vercel/next.js/issues/15637))

![GitHub issue screenshot](https://dev-to-uploads.s3.amazonaws.com/i/xsfl1gsi7yo0hbxhzz72.png)

<a name="chapter-2"></a>
<br />
# How does `fallback: 'blocking'` work? 😲😲

If you're using `fallback: true` in your page, you have to use something like this in your code 😕:

```jsx
const router = useRouter()

if (router.isFallback) {
	return <Loading />
}

return <ProductDetail product={product} />
```

This is for the case when the user visits a page with `fallback: true` for the first time (a page which has not yet been built and whose props from `getStaticProps` hasn't been fetched).

If, however, you use `fallback: 'blocking'` in `getStaticPaths`, you don't use the `if (router.isFallback)` check. That's because when the user visits a page with `fallback: 'blocking'` which has not yet been built, Next.js is first going to build the page and only after it's built it's going the send the response to the user's browser.

You can play ▶️ with the CodeSandbox below the see how `fallback: false`, `fallback: true`, and `fallback: 'blocking'` differ.

{% codesandbox dark-mountain-ibxx4 %}

<a name="chapter-3"></a>
<br />
# When (not) to use `fallback: 'blocking'`?

Generally, the Next.js team encourages you **not** to use it unless is necessary. Using `fallback: 'blocking'` doesn't help the SEO (as Google and other search engine crawlers run JS code and will wait for a `fallback: true` page to load). Using `fallback: 'blocking'` makes the user wait 🥱 without any response while the page is being built and it's better to use `fallback: true` and show a loading skeleton while the page is being built instead.

If, however, you're experiencing issues with OG tags, AMP, or something else due to the usage of `fallback: true`, feel free to switch to `fallback: 'blocking'` 🤗.

You can see the comparison between `fallback: false`, `fallback: true`, and `fallback: blocking` below: ⬇️⬇️⬇️

**`fallback: false`**

![fallback false example](https://dev-to-uploads.s3.amazonaws.com/i/kw7s95h2k9ritq6kcl53.gif)

**`fallback: true`**

![fallback true example](https://dev-to-uploads.s3.amazonaws.com/i/t87kwpxzds8e12ja3zs7.gif)

**`fallback: 'blocking'`**

![fallback blocking example](https://dev-to-uploads.s3.amazonaws.com/i/16ohivnst4mw5reb5bt4.gif)