4

We have a project that contains one dynamic route [productId], and inside this page, we have several other pages that include optional catch-all routes. Here is the structure on the pages folder:

[productId]
  contentOne
    [[...slugOne]]

The issue is, the optional catch-all are not workink properly whenever the pages are statically generated. Ex: productId/contentOne does not work, but productOne/contentOne/extra works The problem occurs only when deployed in vercel. All routes work perfectly on local.

Here is the getStaticPaths:

export async function getStaticPaths() {    
  return {    
    paths: [],    
     fallback: true,    
   }    
 }

Here is the getStaticProps:

export async function getStaticProps({ locale }) {
  return {
    props: {
      test: 'test',
      ...(await serverSideTranslations(locale, ['common'])),
    }
  }
}
juliomalves
  • 42,130
  • 20
  • 150
  • 146
Expedito Andrade
  • 51
  • 5

2 Answers2

1

We have an open issue for this: https://github.com/vercel/next.js/issues/30631

Meanwhile, we had to use rewrites (this goes into the next.config file):

async rewrites() {
return {

  beforeFiles: [

   {
     source: '/:productId/contentOne',
     destination: '/:productId/contentOne/index'
   }
  ]
}
Expedito Andrade
  • 51
  • 5
-1

When using getStaticPaths to generate your pages, setting { fallback: true } does not result in a 404. During development, it works because development uses a version of Automatic Static Optimization where Next is serving up a server-rendered site even if the pages are going to be static.

If you're running a SSR site with Next, then setting fallback will serve up a static page with empty props. That's the expected behavior (if that's what's happening for you) and it's incumbent on you to handle that page either by redirecting client-side or showing your own 404-type or missing content page.

If you're using next export to build and export your pages, then setting fallback does nothing (the expected behavior when using next export) which means that the page just won't exist and your server should handle the 404, either by serving up a 404 error page or redirecting the user somewhere else.

I'm not sure what you mean by "doesn't work" - is it giving you a 404 error or an empty page? Either way, the above is why.

I'm Joe Too
  • 5,468
  • 1
  • 17
  • 29
  • Sorry. Yes. We get a 404 in prod. We're using ISR, not next export, and for standard routes, this has the effect of building "on the fly" which is what we intend. However, for the above routing strategy, if we prebuild, the pages work fine, but for routes that we've not prebuilt, they don't build on the fly in prod, just give out a 404 client side. – Augusto Samamé Barrientos Aug 17 '21 at 22:45
  • BTW. I work with original poster, so took the liberty of commenting on his behalf :) – Augusto Samamé Barrientos Aug 17 '21 at 22:52
  • This link is prebuilt and works: https://staging.ttwithme.com/primrose/social This one is not prebuilt and fails: https://staging.ttwithme.com/expjazzandrade/social. In local, both work – Augusto Samamé Barrientos Aug 17 '21 at 22:57
  • By "doesn't work" I mean a 404. Sorry for not being clear at first. So, we have an empty page for testing, and the page returns a 404. Link: https://staging.ttwithme.com/dummy/test – Expedito Andrade Aug 17 '21 at 23:04
  • @ExpeditoAndrade I'm facing this issue, but instead of fallback: true I'm using fallback: 'blocking'. Did you came to a solution? – giorgiline Jan 10 '22 at 13:18
  • @AugustoSamaméBarrientos or can you tell me something Augusto? – giorgiline Jan 12 '22 at 18:31
  • @giorgiline We were not able to solve this. I have an open issue about it: https://github.com/vercel/next.js/issues/30631. – Expedito Andrade Jan 13 '22 at 15:58
  • @giorgiline We ended up using the rewrites instead of the optional catch-all routes. – Expedito Andrade Jan 13 '22 at 16:01
  • @ExpeditoAndrade, I see thank you, were you using locales? because I think it's a bug related with it. – giorgiline Jan 13 '22 at 16:26