Support for Next.js 13 App Directory about graphql-request

[Kinbaum]

@jasonkuhrt Is the expectation then that I need to instantiate a new GraphQLClient each time I want to make a request? Is there no way to reuse the existing client; then just add this option for individual requests I want revalidated?

Yes, adding the option during instantiation works as expected, I just don't want that to apply to everything or have to instantiate multiple clients, which is why I was hoping for a way to add this option per request; much like how we can say client.setHeaders or client.setEndpoint

[Kinbaum]

I like it. If there’s a specific entry point for next, maybe also include the global fetch next extends as the default

[Kinbaum]

This is next specific. Works on my own infra

[jasonkuhrt]

Yeah they usually do not leverage jsdoc, oh well. Good to confirm thanks for sharing this!

[jasonkuhrt]

Ideas:

• A new entry point: import … from “graphql-request/next”
• A global interface that can be augmented. Still requires user to do something.
• Combine the above two solutions.
• …

[jasonkuhrt]

Does anyone know if this is next specific or Vercel specific or the combination or…?

[jasonkuhrt]

Does anyone know if the next types are consumable easily from a lightweight package? The next fetch extension types might have Jsdoc for one thing which would be nice to inherit.

[Kinbaum]

This is currently how next defines the NextFetchRequestConfig

// Extend the NodeJS namespace with Next.js-defined properties

declare namespace NodeJS {
  interface RequestInit extends globalThis.RequestInit {
    next?: NextFetchRequestConfig | undefined
  }
}

interface NextFetchRequestConfig {
  revalidate?: number | false
}

interface RequestInit {
  next?: NextFetchRequestConfig | undefined
}

[jasonkuhrt]

We also rely on global Nodejs types, so this already works:

[Kinbaum]

Hey @jasonkuhrt not sure why this was closed. There’s no way currently to pass { next: { revalidate: 60 }} to the underlying fetch.

Can you provide an example if I’m misunderstanding something?

This needs to be available on each transaction (client.request) as certain calls are dynamic, while others are static, and some are static with the ability to have their contents “revalidated” after a certain amount of time.

[jasonkuhrt]

@Kinbaum I was trying to show in my last screenshot that the static types are fine with the next parameter added in the context of a Next.js 13 codebase.

Can you clarify what is not working for you?

[Kinbaum]

This option needs to be able to be attached to the underlying fetch, as a sibling of headers, method, body, etc. Currently it’s completely ignored, which prevents static content from being revalidated.

Can probably pass the polyfilled global fetch next provides which looks for this option in the client setup; if it can’t automatically be leveraged

[Kinbaum]

Here’s an implementation example:

request(StaticCMSPageContent, {
  path,
  language
})

This will fetch static page content during the build process.

Now if a content author changes the content and republishes, we need to let next know that this data can change and should be revalidated, without needing to rebuild/redeploy our application.

As it sits right now, this query will never revalidate its static contents.

I am looking for something like this to do that:

request(StaticCMSPageContent, {
  path,
  language
}, { 
  next: { 
    revalidate: 60 
  } 
})

As I mentioned though, this is not a header, it’s special key Next added to the global fetch.

As you mentioned, not a types issue, a runtime problem.

[jasonkuhrt]

I added a test that shows this works. Let me know if that test case is not covering this issue.

[jasonkuhrt]

I understand, you're looking for a feature that would see configuration parity across the function and the class. I agree, but that's a different issue. I'll get around to that eventually, as I overhaul this library. For now you do have a workaround though at least.

Feel free to make a new feature request about the configuration aspects that are lacking for your use-case(s)!

[Kinbaum]

Will do, thanks for the response I appreciate it