Too many requests when rendered conditionally

[mishushakov]

When a component with query is rendered conditionally, gqty makes too many (in my case 5) requests

query.tsx

import { useQuery } from '../utils/client'
import Test from './test'

export default function Example() {
  const query = useQuery()

  return (
    <>
      <p>User: {query.user?.name}</p>
      <div>
        { query.user?.name?.includes('Max') ? <Test /> : 'Not Mish' }
      </div>
    </>
  )
}

test.tsx

'use client';

import { useQuery } from '../utils/client'

export default function Example() {
  const query = useQuery()

  return (
    <>
      <p>Age: {query.user?.age}</p>
    </>
  )
}

[vicary]

There will be a new selection cache covering conditional renders, I am experimenting with a few extreme cases to make sure it neither over-fetches nor under-fetches.

1. No under-fetches
   When it is out, you should see the second fetch including selections from the first one, even if the 2nd render no longer needs it. (At most N fetches, for N rendering conditions.)

2. No over-fetches
   But it will forget all previous selections when a new render is triggered by user events, e.g. A button click changes a state, it in turn changes some query inputs, the last input should not be fetched again.

Does it make sense?

[rbalicki2]

Hey y'all — completely uninformed speculation here, but I wanted to sketch out a possible solution.

From your description, it sounds like you are not targeting initial renders. Is that so? (I don't think a selection cache is a great solution for initial renders of pages, especially when the page is customized to the user (e.g. /user/:id). IMO, that is probably the most important time to avoid waterfalls.)

Okay, here goes. Feel free to tell me I'm wrong.

Things I think are true:

• The gist of the problem is that the component is rendered with fake data (e.g. name: 'asdfasdf'), but there is conditional logic that is opaque to gqty (e.g. if (name === 'gqty'))
• If the field is optional or a boolean, you might have some luck re-rendering to detect data dependencies, but not for a number or string.
• Overfetching is better than underfetching, at least in some cases. (e.g. consider Relay's advice for mutations: just refetch everything that could have changed, as inconsistent state due to underfetching is worse than overfetching.) Besides, defer can optionally be used to avoid paying the cost of overfetching.

Proposed solution

Okay, so the gist is that I think that any conditional branch that you want to be sure gets exercised has to go through a hook that qgty provides. This makes the condition visible to gqty, and means that gqty can re-render the component and exercise all branches you care about.

(It may not need to be a hook! Maybe a regular function works.)

Example

An example that doesn't work, because includes('Max') is opaque to gqty:

export default function Example() {
  const query = useQuery()

  return (
    <>
      <p>User: {query.user?.name}</p>
      <div>
        { query.user?.name?.includes('Max') ? <Test /> : 'Not Mish' }
      </div>
    </>
  )
}

But it can be made to work as follows:

export default function Example() {
  const query = useQuery()
  const isMax = useGqtyBooleanConditional(() => query.user?.name?.includes('Max'));

  return (
    <>
      <p>User: {query.user?.name}</p>
      <div>
        { isMax ? <Test /> : 'Not Mish' }
      </div>
    </>
  )
}

Now, when gqty renders the component, it notices that we're calling useGqtyBooleanConditional, and then knows to re-render twice. Once returning true and once returning false.

Additional thoughts:

• can this be turned into a @include statement? This is unclear to me.
• I think everything that is fetched only in a branch can be given @defer. This means that for a given user whose age > 65, the query will not be blocked on YouthCard and vice versa, even though that data is eventually fetched.
• This is entirely opt-in. Users may be happy with waterfalls and not need this.

[vicary]

@rbalicki2 tl;dr You may pass prepare function to useQuery hook to do exactly that.

The issue boils down to initial developments where fields may change rapidly, or not known beforehand, that's where GQty focus the most. At the moment it means for each conditional code path, there will be 2 renders (1 with suspense) and 1 fetch.

With the prepare option, GQty grabs selection from there instead. This way, subsequent renders never trigger further fetches.

When using without prepare, null values and empty arrays returned from server essentially stop the proxy from receiving child selections. That's when the selection cache comes into play.