How to conditionally preload a query with tanstack?

[erickreutz]

Imagine I have a route that accepts an optional query parameter. like /new?id=123 And on this route, we render a form. And given that we have an id we want to pre-load a resource to pre-populate parts of the form. How can I preload a query conditionally based on the presence of a query parameter.

export const Route = createFileRoute("/new")({
  loaderDeps: ({ search: { id } }) => ({ id }),
  loader: async ({ deps, context }) => {
    if (!deps.id) {
      return { queryRef: null };
    }

    // How to skip this?
    const queryRef = context.preloadQuery(MY_QUERY, {
      variables: { id: deps.id },
    });

    return { queryRef };
  },
  component: RouteComponent,
});

function RouteComponent() {
  const { queryRef } = Route.useLoaderData();

  // This breaks when queryRef is null
  const { data } = useReadQuery(queryRef);

  return </>;
}

[phryneas]

What about

 const { data } = useReadQuery(queryRef ?? skipToken);

? :)

[erickreutz]

I didn’t think useReadQuery supported skipToken

[phryneas]

Oh wait, that's true, my bad.

Usually in those cases we recommend conditionally rendering two different child components - one for the undefined case and one for the queryRef case.

Of course that seems suboptimal for your case of "just potentially prefilling a form".

Other option I could think of to use useSuspenseQuery here, and pass skipToken into that if the queryRef is undefined.
It will latch onto the ongoing preloadQuery and not make another request. But I admit it seems a bit hacky.

I'll bring this up in our next team meeting, too.

[jerelmiller]

@erickreutz FYI one of the reasons we've been hesitant to add support for undefined or skipToken is because we are trying to push towards conditionally rendered components as a pattern.

Skipping creates a natural fork of your UI where you typically render a fallback in cases where data isn't available due to the skipped query. We look at that problem and suggest using conditionally rendered components as the way to handle that split, that way the fallback UI/rendered UI don't get tangled together. So in this case, we'd recommend something like:

function RouteComponent() {
  const { queryRef } = Route.useLoaderData();

  return queryRef 
    ? <UIThatUsesData queryRef={queryRef}> 
    : <FallbackUI />;
}

We find this lends itself to scale a bit better because you can avoid littering that UI with a bunch of conditionals to handle whether data is available or not.

That said, your case is one of the first I've heard that feels like a valid use case since you're rendering the some form in both cases. I want to ask a couple other questions though.

What happens in that form if the data from useReadQuery changes due to a cache write? Do you rerender the form with the new data? Do you discard any user changes? Or are you looking purely for a means to populate the initial values of the form only?

I ask because preloadQuery might be the wrong tool here. You'll need to handle the problem of cache updates if you're using useReadQuery since data may change to keep it in sync with the cache. If you're looking to simply prepopulate the initial values of the form, I'd suggest using client.query directly. That will let you load data and consume it directly without the need for the additional hook in your RouteComponent.

export const Route = createFileRoute("/new")({
  loaderDeps: ({ search: { id } }) => ({ id }),
  loader: async ({ deps, context }) => {
    if (!deps.id) {
      return { data: null };
    }

    const { data } = await client.query({ 
      query: MY_QUERY,
      variables: { id: deps.id }
    })

    return { data };
  },
  component: RouteComponent,
});

function RouteComponent() {
  const { data } = Route.useLoaderData();

  return </>;
}

[erickreutz]

@jerelmiller thanks for the detailed write-up. I have been using client.query directly and it seems to be working well. I wasn't sure if that was the suggested path forward or not, given that useReadQuery didn't support skipToken. But it looks like it is. Thank you!

[jerelmiller]

Glad to hear that works!

Yep totally fine to use it! We just fine that 95% of use cases would be better off with preloadQuery since it will rerender with cache updates. You've got one of the few use cases that don't really benefit from this. Regardless, we probably can/should put something in our docs that say its ok under certain conditions 🙂