DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Tom Dohnal
Tom Dohnal

Posted on • Updated on • Originally published at tomdohnal.com

Blocking Fallback for getStaticPaths–New Next.js 10 feature

Table Of Contents



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)

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

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

GitHub issue screenshot



How does fallback: 'blocking' work? 😲😲

If you're using fallback: true in your page, you have to use something like this in your code πŸ˜•:

const router = useRouter()

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

return <ProductDetail product={product} />
Enter fullscreen mode Exit fullscreen mode

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.



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

fallback: true

fallback true example

fallback: 'blocking'

fallback blocking example

Top comments (7)

Collapse
 
hidongdongzhang profile image
Dongdong Zhang • Edited on

The comparison pictures clearly tell the difference between true and block

Collapse
 
kpirumyan profile image
Karen Pirumyan

And what will happen if you set fallback=true or ='blocking' and try to open, say, tens of thousands of non-existent pages using some script? This will generate countless pages in the build folder, won't it?

Collapse
 
minhhunghuynh1106 profile image
igdev

Thanks a lot, so clean and easy to understand for beginner with Next! 🍞

Collapse
 
viskazz profile image
Viskazz

Hi, Tom! Thanks for great post! I'm worry about seo for this kind of approach. How do you think, is any issues there for seo with fallback:true or fallback:'blocking' ?

Collapse
 
tomdohnal profile image
Tom Dohnal

Hi Viskazz! Happy you liked it.
The only SEO issue might be if you use fallback: true and the crawler which is crawling your website doesn't wait for JavaScript to be executed and the page to be fully loaded.
However, this only is the case for some crawlers which create page preview for social media posts.
For Google and other search engine crawlers it shouldn't make a difference :)

Collapse
 
mortezasabihi profile image
Morteza Sabihi - #OPENTOWORK

Thanks for your clear explanation.

Timeless DEV post...

How to write a kickass README

Arguably the single most important piece of documentation for any open source project is the README. A good README not only informs people what the project does and who it is for but also how they use and contribute to it.

If you write a README without sufficient explanation of what your project does or how people can use it then it pretty much defeats the purpose of being open source as other developers are less likely to engage with or contribute towards it.