Allow for partial getStaticPaths

[nicholaschiang]

Feature request

Is your feature request related to a problem? Please describe.

For the Tutorbook website (source available here), we have i18n setup such that each page has a getStaticPaths and getStaticProps that gets the translations for the current locale. Our pages directory is setup like:

.
├── api
│   ├── account.ts
│   ├── appt.ts
│   ├── people.ts
│   ├── redirect.ts
│   ├── request.ts
│   ├── search.ts
│   └── user.ts
├── _app.tsx
└── [locale]
    ├── approve.tsx
    ├── dashboard
    ├── index.tsx
    ├── [org]
    │   ├── dashboard
    │   │   ├── index.tsx
    │   │   └── people.tsx
    │   └── search
    ├── search
    │   └── [[...slug]].tsx
    └── signup.tsx

7 directories, 15 files

But, we have a use case where we want an [locale]/[org]/dashboard route to use automatic static optimization for the org param only. That is, we want to statically fetch and render a skeleton screen with the locale query param and then use SWR to fetch the org specific data once Next.js hydrates the page client-side.

I want a dashboard to be at /[locale]/[org]/dashboard but I want to statically pre-render a skeleton screen (i.e. when I don't know org but I do know locale) and then fetch the user's data client-side once Next.js hydrates the page and triggers an update to the query object (see this documentation).

Describe the solution you'd like

Allow for getStaticPaths to output a subset of the dynamic path parameters and then getStaticProps has access to that subset of parameters. Next.js should then pre-render that page with the specified subset of parameters (i.e. pre-render a different dashboard skeleton screen for each locale).

Note: The dynamic path parameters specified by getStaticPaths should be higher up in the directory structure than any unspecified parameters (i.e. I can specify a locale without specifying an org but I can't go the other way around).

Then, all remaining dynamic path parameters (i.e. the org) are then provided client-side when Next.js hydrates the page (i.e. like it does currently with automatic static optimization).

Describe alternatives you've considered

Currently, I'm forced to either SSR that page or fallback to the default locale (to pre-render that skeleton screen) until Next.js hydrates the page. Once Next.js hydrates the page, I now know locale and can manually fetch the necessary JSON translations. This is because we're forced by Next.js to provide all page routes when using getStaticPaths (i.e. we can't just provide a locale, we have to provide a locale and a username).

[nicholaschiang]

Note: This is made even more complicated given the fact that only certain users have access to certain org dashboards.

Because all of our authentication sessions are stored client-side (i.e. we have a REST-ful API that accepts a JWT from the client), we can't SSR the whole dashboard (i.e. we can SSR the skeleton screen but all user-specific data must be fetched client-side).

And then because of the restrictions of getStaticPaths (i.e. we have provide all dynamic path parameters), we can't pre-render a skeleton screen for every possible org dashboard (e.g. if Vercel had localization like we do, they'd have to pre-render millions of skeleton screens for each team).

[jesstelford]

There's an open Discussion for this topic here: #14486

[skrivanos]

+1. Mainly chiming in to say that this feature would improve things a ton when it comes to translating dynamic routes (for instance with next-i18next@8). getServerSideProps isn't really a good option since it adds considerable latency.