Fetching nested data on SSR'd page

[czuniga-xtages]

Hi,

I'm evaluating different frameworks for my startup and Blitz is certainly looking very solid, kudos to the authors and community!

As for my specific question, I want like to SSR a page with a complex hierarchy of components (some pseudo code below)

<Page>
    <CompA>  // uses DataA, needs it for SSR
        <CompB>  // uses DataB, can be client-side loaded
           <CompC/> // uses DataA and DataC, needs it for SSR
       </>
    </>
</>

and I'd like to be able to smartly determine which data should be fetched from getServerSideProps and pass it down.

In the example above it would be DataA and DataC also making sure that DataA is only fetched once, if it makes a difference the data would be fetched from an API server not the DB.

Is there an established pattern, library or built-in to accomplish this?

What I'm trying to avoid is:

1. Lots of hand rolled code in getServerSideProps
2. Adding another component to the hierarchy and forgetting that we should be fetching data for it in getServerSideProps

Thanks

[MrLeebo]

If CompA and CompC are querying data with useQuery() and you want that data to already be fetched in the initial render, I think what you would do is perform the data fetches in getServerSideProps (gSSP) and pass it as props or context to the initialData option of your query.

export default function Page({ initialDataA, initialDataB, initialDataC }) {
  return (
    <CompA initialData={initialDataA}>
      <CompB>
        <CompC initialData={initialDataC} />
      </CompB>
    </CompA>
  )
}

export async function getServerSideProps({ req, res }) {
  const initialDataA = await (...)
  const initialDataC = await (...)

  return { props: { initialDataA, initialDataC } }
}

and a CompA like:

interface Props {
  initialData: SomeDataObject
}

function CompA({ initialData }: Props) {
  const { data } = useQuery(getDataA, inputs, { initialData: initialDataA })
  return (...) // do something with query data
}

if your components are well-defined and you're using TypeScript to define your Props, then this issue basically becomes a compilation error; the code simply won't compile until you've provided a valid initialData prop to CompA, which you can only do by writing the gSSP.

However, it sounds like you're thinking of it as if CompA is dictating to gSSP about whether or not the page should be server rendered, but that isn't the component's job. Actually it is gSSP that is responsible for making that happen. So you could delete the useQuery() entirely and let the CompA render directly off of the initialData prop and then it would have no choice but to be server rendered.

[czuniga-xtages]

Hey @MrLeebo thank you so much for your response.

However, it sounds like you're thinking of it as if CompA is dictating to gSSP about whether or not the page should be server rendered, but that isn't the component's job.

I guess what I'm after is a way to specify that CompA should be provided with initialData if rendered server-side and otherwise let it fetch it from the client-side without necessarily coupling that knowledge (at least by hand) in getServerSideProps. This is probably a non issue with very simple pages but I do wonder if it becomes unwieldy as the nesting increases.

[flybayer]

I think currently we don't have a good pattern for this, but we absolutely want to support this. Probably we'll wait for server components to land as there's likely significant overlap with that.

[czuniga-xtages]

Gotcha. Thanks for the response!