[RFC] Static props + Live updates: getStaticPropsQuery

[jxe]

I often have pages I want to pre-render statically (using getStaticProps), but once they load, there are conditions when I want to reload that data (using useQuery).

I see at least two possibilities.

Option 1: getStaticPropsQuery

import query from 'app/queries/query'
export function getStaticPropsQuery(params) {
  return [query, { queryParam1: params.param1 }, { initialStale: true }]]
}

This would be a new export from pages that replaces getStaticProps, and—instead of generating the props directly—returns the args for useQuery based on the route params. These can then be used as the static props and place the page within a wrapper that dynamically updates them (just wrapping the page inside a useQuery with the returned args).

function Page({results, of, theQuery}){ ... }

export default Page

Option 2: prop-less pages

An alternative would be to have pages with no props, and use a hook for page data. This takes us further from next, but is less magical.

Pages would be allowed to have getStaticPaths but no getStaticProps. Instead, useQuery runs on server side.

export function getStaticPaths(){ ...}

function Page({}){
  // the following runs during static generation *and* after hydration.
  const {params} = useRouter()
  const [{would, haveBeen, pageParams}] = useQuery(query, {..}, {..})
}

export default Page

Thoughts?

For reference, here's the twitter thread where this was initially discussed: https://twitter.com/edelwax/status/1331735357700894727/photo/1

[flybayer]

Oooh, cool ideas!!

Here's another option:

Option 3: extend getStaticProps

export async function getStaticProps(context) {
  return {
    props: {someThingElse: ''}, 
    useQuery: [getInventory, {where: {id: context.params.productId}}, {staleTime: 5 * 1000 * 60}]
  }
}

function Page({queryData, queryExtras, someThingElse}) {
  return (
    <div>
      Inventory: {queryData.count} 
      <button onClick={queryExtras.refetch}>Refresh</button>
    </div>
  )
}
``

[jxe]

This seems better than my option 1. And likely makes more sense than option 2, so long as next.js is how it is, and blitz so closely tied.

But there’s something sweetly ‘isomorphic’ and low learning-curve about 2.

[flybayer]

Yeah. At some point we'll definitely tackle isomorphic useQuery, likely once the new React streaming SSR renderer is ready.

[jxe]

Option 4: Build this (server-site prefetching and query cache hydration) into blitz!

I was unaware that there's an official react-query + next way to do this! (Since react-query 2.13.0).

https://react-query.tanstack.com/docs/guides/ssr#integrating-with-nextjs

 // pages/posts.jsx
 import { QueryCache } from 'react-query'
 import { dehydrate } from 'react-query/hydration'
 
 export async function getStaticProps() {
   const queryCache = new QueryCache()
 
   await queryCache.prefetchQuery('posts', getPosts)
 
   return {
     props: {
       dehydratedState: dehydrate(queryCache),
     },
   }
 }
 
 function Posts() {
   // This useQuery could just as well happen in some deeper child to
   // the "Posts"-page, data will be available immediately either way
   const { data } = useQuery('posts', getPosts)
 
   // This query was not prefetched on the server and will not start
   // fetching until on the client, both patterns are fine to mix
   const { data: otherData } = useQuery('posts-2', getPosts)
 
   // ...
 }

Seems like the way to go! Plus some additional sugar over how react query is used in getStaticProps. Perhaps just (1) a flag in getStaticProps to create and hydrate the server side cache, (2) your version from option 3, or (3) a function import in getStaticProps that you call to prefetch and hydrate queries.

[flybayer]

Yeah, good point! This seems like a good direction to explore. Would need some way to define which queries you want prefetched in gSP and which you don't.