Multiple queries on one page

[reverecre]

Multiple queries on one page

[k0ka]

fetchPolicy is applied to the whole query.

if any piece of data for that query is missing or stale, it will fetch the entire query from the network.

So in my case it will refetch entire query including user top on each page.

[rrdelaney]

@k0ka That's a good point about variablesFromContext not working the same anymore.

@FINDarkside Using an array or just changing the type of the second argument can get weird. For example, if we modify relay-nextjs to detect arrays in the second argument, but then a later change to Relay switches the compiled output of queries to also be arrays we will never have the correct behavior.

[FINDarkside]

Was just thinking about this and realized this would also solve the underlying issue in #73. Or at least be a workaround for it.

[FINDarkside]

Could you give some example use case? In what case would you need multiple queries instead of using fragments to make them into one query? Using multiple queries for a page seems like an anti-pattern unless I'm missing something.

[k0ka]

We have the "Top users" block on the sidebar of each page. It is changed infrequently and might be cached. We can't do it using one query as we can't cache query parts in Relay.

[FINDarkside]

We can't do it using one query as we can't cache query parts in Relay.

You can cache query parts if you want and relay will only fetch the data that is not in the cache. By default this library uses store-and-network fetch strategy meaning that it'll first use the cached data and then re-fetch it. If you want to avoid fetching data that is in the cache you should change the fetchPolicy to store-or-network.

[FINDarkside]

Hey you're absolutely correct, I had the wrong impression of how relay uses the cache! I now see the use case for this and might use this myself if it gets implemented. In perfect world I think this should be react-relay feature though (fragment/field specific caching). That's probably not going to happen though. :(

E: Apparently relay classic did only fetch the data not in cache, but that feature was discarded in relay modern for some other benefits.

[rrdelaney]

This seems like a worthwhile feature to implement. I've thought about the API a bit and would definitely like to do it in a backwards compatible way. What do you think about something like this:

function MyPageComponent({
  preloadedQuery,
  additionalQueries,
}: RelayProps<{}, page_Query>) {
  const pageQuery = usePreloadedQuery(MyPageQuery, preloadedQuery);
  const secondQuery = usePreloadedQuery(SecondQuery, additionalQueries[0]);
  const thirdQuery = usePreloadedQuery(ThirdQuery, additionalQueries[1]);

  // ...
}

export default withRelay(MyPageComponent, MyPageQuery, {
  // ...
  additionalQueries: [SecondQuery, ThirdQuery],
});

This should preserve backwards compatibility, maintain the simple API for most pages, but allow the flexibility of multiple queries.

[FINDarkside]

Personally I think it would be more clean to add new prop preloadedQueries which includes all queries (including the first one) in array. preloadedQuery could be kept just for backwards compatibility, but wouldn't be the "best practice" anymore, at least not when using multiple queries. Second argument to withRelay could accept array of queries and also support non-array for backwards compatibility.

[k0ka]

We should also think of variablesFromContext and fetchPolicy as they must return values per-query. I think it's a good feature that variablesFromContext is fully typed, so TypeScript users will have compile-time errors if they forgot anything.

In my PoC it is implemented as:

export interface WiredOptions<Queries extends {[key: string]: OperationType}, ServerSideProps> {
  variablesFromContext?: (ctx: NextPageContext | NextRouter) => { [K in keyof Queries]: Queries[K]['variables'] };

So the variableFromContext function must return an object like

{
  query1: {
    variable_for_query1: "value",
  },
  query2: {
    variable_for_query2: "value",
  },
}

and it tracks variable types.

We might provide two HoCs: leave the current one and create a new withRelayMulti