Make getStaticProps support URL query string

[ivawzh]

Feature request

Hi NextJS. Thanks for the great OSS.

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

As getStaticProps now support fallback and server-side SWR, it'd be much more useful if GetStaticPropsContext supports URL query string like ?foo=bar.

Our users spend the largest amount of time on searchable pages, such as /products?brand=x, /restaurants?type=italian, /products/that-t-shirt?size-max=12, etc. It is essential for getStaticProps to support fallback with either full URL or query string as params. Otherwise, we can only adopt GSP for a very small portion of pages. Feel like a waste of such a valuable feature.

Describe the solution you'd like

I'd prefer NextJs to keep it simple and provide a URL path string as it is now from NextContext of getInitialProps. So that we can customize the way to parse these URLs.

Describe alternatives you've considered

Currently, there is already a params provided in GetStaticPropsContext, but it excludes the query string. It'd be okay if NextJS put query in GetStaticPropsContext like existing GSSP and route.query. It's just that the query string formats for recursive/SEO-friendly object and array are always subjective and questionable.

[youminkim]

Have similar use case. My search page url is like /search?title=vercel&page=1 and I want to use the incremental static regeneration. I may hack like /search/vercel/1 but supporting query string would be much better

[lucasbasquerotto]

I propose being able to export a function that allows defining the query parameters that should be used to generate different static pages (because you probably don't want to generate a different static page if the only changed parameter was utm_source, for example).

Example for mypage/:slug:

mypage/slug1 -> static page1
mypage/slug2 -> static page2
mypage/slug1?query=value1 -> static page3
mypage/slug1?query=value2 -> static page4

(they would behave similarly to mypage/[slug]/[...rest], although rest in this case would not be a part of the path.

In this case, I would expect to generate the pages statically, and returning the statically generated page based on the slug and query parameters.

This is very important if you want static pages with pagination that have the page number in the query, or for pages that have a search mechanism and the search params are sent in the query (which is natural, although it could be passed in the path too).

The query parameters that would be considered could be specified in a method similar to getStaticProps() and getServerSideProps(), but to define query parameters to be considered to render different static pages. Like the following proposal:

Proposal: getStaticParams

export function getStaticParams() {
    return ['page', 'order'];
}

This method would return an array of strings with the query parameters that should be considered for SSG, similarly to how it already happens in the case of slugs in the page path, and at the same time it would also able to ignore parameters like Facebook fbid that are not relevant to render the page.

In this case it would generate different static pages for /example, /example?page=2 and /example?page=2&order=desc, but the urls /example?page=3 and /example?page=3&utm_source=abcde would return the same static page.

[javiercr]

We have the exact same use case, we need to be able to paginate with query params (?page) and still be able to benefit from using getStaticProps.

[LPIX-11]

This getStaticParams proposal is awesome and would solve so many performance related issues, I currently have a database with over 1k products and was using SSG and it was working so fine ..... until I realized using that users cannot directly filter/search the products they wanted on the url, they had to go through searchbar and do it.
So I switched to SSR and man the page's loading as fast as a snail compared to SSG 🥺

[LPIX-11]

The difficulty would be that SSG creates HTML pages at build time BUT I think this could be solved like this:

• All args from getStaticParams are usable in the parameter like

  export function getStaticParams() {
      return ['page', 'order'];
  }

  // When generating static paths on dynamic routes
  export async function getStaticPaths() {
    let paramList = [];

    [
      'all',
      'shoes',
      'shirts',
    ].forEach(bundle => {
      paramList.push({
        params: {
          bundle: bundle,
          page: '1',
          order: 'asc'
       }
      });
   });

   return {
      paths: paramList,
      fallback: true
    }
  }

• Then let the fallback property do it's job (which is every time the user changes the given query parameter eg: ?page=2 it would quickly generate statically a new page.

[lucasbasquerotto]

@LPIX-11 Yes, I made the proposal intended to be used with fallback=true, in the same way that it verifies the path to resolve which static page to return (and generating it when not generated yet), but now it would also consider what is returned by getStaticParams() (when defined) at build time to resolve which page to return, based on the url path and parameters.

[flaviolivolsi]

I have the same issue as @lucasbasquerotto: in my case I want to get the same regenerated page taking into account only the slug, especially because for traffic coming from Facebook Ads there's the query param fb_click_id constantly changing, hence users would always see an old version of the page in case the manual build wasn't triggered after the last change of the page. This is a major issue for me (right now I had to enable a manual build via webhook for each change, so unfortunately the incrementai regeneration is rather useless in my case).

[felixmeziere]

Hi!

We have the same issue, I would like a certain number of selected, frequently visited or SEO-friendly search results to be SSGed and can't due to query parameters not being handled by getStaticPaths/Props :/

https://beta.greengo.voyage/hosting-search?name=France&placeId=ChIJMVd4MymgVA0R99lHx5Y__Ws&numberOfBabies=0&numberOfChildrens=0&numberOfPeople=1

Have like a hundred of versions of this page SSGed basically, corresponding to search results valued by the business for specific purposes.

[nagman]

Totally agree with those ideas of including params in the context object given by getStaticProps, and creating a getStaticParams to filter out the GET params we don't want to be considered by getStaticPaths.

In my case, I have a small blog with pagination, and it could be very fast with GSP (I could build all the pagination pages in getStaticPaths), but as the client wanted a single simple teeny-tiny search input, I'm forced to use GSSP and now the page loading is soooooo slow :(

Would be awesome to use fallback with query params!

[FabianL1]

We also have this use case. I would love to have this.

[defrex]

I also have this issue.

Everyone seems focused on a new getStaticParams function, but couldn't getStaticPaths handle it? For example,

export async function getStaticPaths() {
  return {
    fallback: false,
    pages: [
      { params: { pathSegment }, query: { getParam } },
    ],
  }
}

That would certainly suit my needs, and IMO it makes sense to treat dynamic path segments and GET params similarly.

[saikrishnabanda5]

Will that work @defrex

[nghiepdev]

Are there Next.js core members here?

[VinayaSathyanarayana]

Please see #22012 and #22333

[samuelcastro]

+1 for this, it'd be very helpful!

@timneutkens do you guys have any plans to implement this any time soon?

Thanks!

[paul-vd]

Yea would be awesome to see this.

Currently my solution is to have one static generated page with all known paths/params, and then a second server side page which handles any custom filters with queries.

pages/
├── posts/
│   ├── [page].tsx (handles all static generates pages, e.g. paginated results)
│   ├── index.tsx (handles any custom queried results, e.g. `?search="My post"&page=0&limit=20`
└── post/
    └── [slug].tsx

[IikkaWinter]

I was actually thinking about solving it similarly on rewrites level but couldn't find a way to achieve it. Care to share some more details on this implementation?

[mustkem]

Can you try something like this If you are trying to rewrite some implementation?

[?queryString].js // dynamic index.js

Then

export async function getStaticPaths() {
return { paths: [
{ query: { page: '1' } },
{ query: { page: '2' } }
], fallback: false };
}

and

export const getStaticProps(
async ({ params, store, ...rest }) => {
const result = await ... // fetch data using params.query
return { props: { result } };
}
);

[ivanjeremic]

I was thinking to do it similarly, in my case I would have moved the [slug].tsx also in the /posts directory, don't know if this will work better/cleaner

[nghiepdev]

[IikkaWinter]

Your example works for catching path params but this discussion is focused on query params (the ones after ? in url).

[jhemarcos]

Another point that is directly related to this request is the possibility of also accessing the host that is making the request within getStaticProps.

I saw in some issues members of Vercel team discarding this possibility saying that getStaticProps will be executed at build time, and therefore there is no access to the request object. However, since the fallback option (including its blocking value) has been added, we must consider use cases where getStaticProps will be run on the production server when the fallback is true.

A very clear case where it is necessary to know which host within getStaticProps is the case of a page that runs on multiple domains (tenants) and that needs SEO. Using getStaticProps currently I just can't get the absolute url for the page, so I can't set the meta tags correctly, like og: url.

[realw5]

Another use case is A/B testing, specifically, where you want to have performance and SEO unaffected. A cookie could be used as a cache key and along with fallback: blocking you could have two cached versions of the SSG page. This is very common in eCommerce uses cases.

My thought is to expose an API within getStaticProps that allows us to manage the cache keys and other (CDN) related functions such as revalidate. Unless I am missing something, I don't understand why this isn't possible and don't understand why it would be hard to expose.

[nihakue]

**Hot take**: I'm probably over simplifying things, but I see very little reason why getStaticProps and getServerSideProps should have totally different APIs, and when you pick one you get locked out of seemingly unrelated features only available to the other (I'm looking at you, prefetching). Effectively SSG and ISR are caches, why not transparently treat them like caches instead of being opaque about it? Splitting users into two tracks and supporting some features in one track and not in the other creates a divided ecosystem and lots of maintenance overhead. Is there a good reason not to just have `getProps` and allow users to configure any caching as their needs require? getStaticPaths is just pre warming the cache, why not make it less opaque by exposing a `prewarmCache` or `preload` API where users can make/describe any requests (including headers, query params, path, etc) as needed? I'm already seeing issues with the cache-that's-not-a-cache approach: 1. SSR routes cannot have their json data prefetched. Why? Why do I have to rewrite my entire app to use getStaticProps (and give up access to query params, headers etc) just to take advantage of this feature? Sure, make it opt in so that people don't accidentally blow up their origin, but I don't see why it's limited to SSG 2. No access to the request and response object in getStaticProps routes. Yes, I get that these routes will be served from the file system (cache), but why not let users define their own cache keys and stick some basic cache eviction on there to prevent the cache exploding if a user decides they want to cache on every query param and header. There *is* a request object during revalidation / initial generation, and access to that can be incredibly powerful, even for 'static-ish' content. [Cloudfront does this](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-announces-cache-and-origin-request-policies), as does [Cloudflare](https://support.cloudflare.com/hc/en-us/articles/115004290387-Creating-Cache-Keys) and it's tremendously useful. 3. No ability to programmatically invalidate the SSG/ISR cache. Any cache should have the ability to clear all or part of it when we know the content has changed. Computing ETags is expensive when you're using a DB or CMS to drive your content. It's much more performant to push an invalidation on content changes. I can tell that my tone is a little combative, I'm not meaning to be. I think Next.js is a great project with a lot of great direction, but this one thing feels a bit off to me.

…

On Mon, Apr 5, 2021 at 12:21 AM Jean Marcos ***@***.***> wrote: Another point that is directly related to this request is the possibility of also accessing the host that is making the request within getStaticProps. I saw in some issues members of Vercel team discarding this possibility saying that getStaticProps will be executed at build time, and therefore there is no access to the request object. However, *since the fallback option (including its blocking value) has been added, we must consider use cases where getStaticProps will be run on the production server when the fallback is true.* A very clear case where it is necessary to know which host within getStaticProps is the case of a page that runs on *multiple domains (tenants)* and that needs *SEO*. Using getStaticProps currently I just can't get the *absolute url* for the page, so I can't set the meta tags correctly, like og: url. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17269 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAS6R3RUAHSHWEALIGHB6ETTHDX67ANCNFSM4SSFBLSQ> .

[thomasdavis]

A url is a url,
a path is a path,
semantics mean not much at best
— a string,
they shouldn't follow the Cache King's "convention" here.
Unless he prefers his servants eat Spaghetti and
their own married misses.

---

The actual answer for anyone who cares is to use something like Cloudflare workers or Varnish (perhaps fastly) to rewrite at the http layer the query into a path based route, aka you can't use Vercel's routing layer. (without using their functions and a thousand rewrite rules, which at that point, it's probably better to use the options above)

[mengqing]

I seem to have the exact opposite requirement to the OP. For us, we want /example to be statically generated, but anything with params eg: /example?foo=bar to not be statically generated and just renders.

Is there a way to do this currently without having to separate into two different pages?

[pumuckelo]

What?? How do you have this problem if static site generation is not working for query parameters?

[lucasbasquerotto]

@pumuckelo I think he means that today both cases are statically generated as the same page, but he wants the one without parameters to be statically generated, while the other would be rendered (I don't know if he means at the server side or client side), and it would be different from the statically generated (and in cases of different parameters).

[pumuckelo]

@lucasbasquerotto Ah okay, thank you.

But the case with the query parameter cannot be statically generated doesn't it?

Path parameters can be statically generated /post/[post].tsx
But query cannot /post/superpost?page=2

Or am I wrong?

[lucasbasquerotto]

@pumuckelo It can't today, that's why he posted his use case here (because this discussion is about supporting url query parameters aside from path parameters, so as to generate 2 different static pages), although his case is a bit different, because with query parameters he doesn't want to statically generate the page.

If this feature is implemented, there's a good chance to support his use case too. For example, if there are query parameters he could just return a skeleton and render at the client side based on the parameters. I don't know if it would be possible if he wants to render at the server side, tough, maybe it won't be possible even if this feature is implemented, because the page should support both ssr and ssg, which I don't think is supported (maybe it could be achieved with rewrites?).

[Previesam]

@pumuckelo /post/[post].tsx once statically generated will always respond to requests for /post/whatever and /post/whatever?foo=bar.

[waqas-nr]

+1 for this, it'd be very helpful!

I have the same case but I am unable to get query params in getStaticProps. Next.js v13

[hk86]

Any plans for a solution in nextjs 13 with appDir? My use case is that I need one searchParam which might have 5 different values for each page. Currently I need to switch to dynamic rendering although static rendering is what I want.

[DDTORRES055]

Same problem, I can´t set the searchParams on generateStaticsParams to generate static pages with query params, I think there should exist a generateStaticQuery method or something like that for generating static pages supporting query params

[dedegkaev]

Same problem! Is there a solution?

[petewarman]

Similar problem here though mine has an additional need to generate different responses based on a request header as well as the search params.

We have product pages with product types that are available in multiple colour and size options. The url structure is like /product-slug/{colour-variant}/product-id?size={size-variant}. Generally we want search engines to index all the colour variants but not the size variants therefore colour is part of the path but size is part of the query string. However, we'd like to be able to statically render all colour and size variant combinations.

To complicate matters further we also have a service in front of our application that sends through a header containing a list of AB test feature flag settings to render the page with. So in order to use ISR we'd need access to this too.

It's kind of crazy that we're building exactly the sort of application that nextjs would shine for but we can't use a core feature like this because we have no control over what's included in the cache key.

[mark8819]

+1 for this!

[nikhil-builds]

Any solution yet for this?

[kradyy]

Following

[mauron85]

Wondering if it is not possible to use redirects in next.config or middleware to achieve this?

mypage/slug1 -> static page1
mypage/slug1?query=value1 -> static page3

// next.config.js

module.exports = {
  async redirects() {
  {
        source: '/mypage/slug1',
        has: [
          {
            type: 'query',
            key: 'query',
            value: 'value1',
          }
        ],
        permanent: false,
        destination: '/mypage/slug3',
      },
  }
}

[ReemX]

Following this too!, I have a page called /houses and also a dynamic one called /houses/[id] now I only have 15 houses on the website thus I used generateStaticParams and next js now uses SSG to render all those house pages statically only in build time the thing is, at the /houses route where the user can see all the houses I have a place where they can filter the house in some ways, but not that many combinations, I filter through the query parameters and as soon as I use searchParams my page automatically becomes dynamic, which I don't want! we need a solution not only for dynamic routes (aka [id]) but also for searchParams aka /houses?min-price=300 so even if I have 20 different filter combination I can use SSG and pre render them all in build time saving major costs in requests!

edit: there is one solution I came up with which I dont like, instead of using /houses to display the houses I can seperate them so /house/[id] is one route and /houses/[filter] is a second route but it is a really dumb solution because as soon as I want multiple queries it becomes very weird to manage

[jayxiaoy]

Following

[pedromtec]

Following

[antonius-dev]

following

[surajair]

following

[sovetski]

any news here?