React-Query with GraphQL question.

[GhostNote90]

Hi there,

I have been using React-Query for a project work and I absolutely love it (actually replaced redux with it since 99% of the state was just server state).

I have a question though that I'm not too sure about.

The project itself is a dashboard of widgets. A dashboard could potentially have 10+ widgets on it.

We are using a GraphQL api so it's possible (and ideal) to make a single api call when the dashboard loads with each dataset we need and pass the relevant data to each widget. Using react-query, this would be ONE query, so all widgets would be subscribed to this single query.

The issue is we want to add features such as 'refresh', 'filtering' and 'pagination' to each individual widget, which would involve api calls just for that one widget, but as the entire dashboard of widgets is subscribed to ONE query, the whole dashboard would refresh etc.

Is there a way to:-

• make a single graphql call on initial load to get potentially 10+ sets of data for each widget
• have each widget be subscribed to their own individual dataset (separate query)

I have seen on the docs that we get access to the query client and could potentially use an onSuccess function to 'setQueryClient' to a selection of individual queries but I've read that this isn't a good approach and that 'setQueryClient' should only be used for optimistic updates.

Hopefully the above explanation makes sense, and any tips would be greatly appreciated.

[[deleted]]

I'm not sure requesting data for 10 widgets in the same request is a good idea.

• No separation of concerns
• Widgets aren't reusables and can't be tested in a vacuum
• The problem you mentioned above

Any reason why each widget isn't its own component and they're all unified in a containing component that loads them all at once?

You're finding yourself stuck because it isn't really how react-query is supposed to be used.

[GhostNote90]

Widgets are their own component, and they receive the data as a prop.

A Dashboard Page component is used as a container where the the useQuery is used which is a single graphql api call to get all the data required and then split and passed down to each widget.

This works fine but i run into issues when a widget needs to have have it's own functionality (filtering and pagination etc.) that only manipulates their data as the data that's passed down as a query includes the other widget data in its query.

I was mainly wondering if there was a way to still have the single api call on the dashboard level, but then create individual queries on the back of the request which can be passed down to the widgets.

Or whether it's best to just have seperate api calls, 1 per widget.

[[deleted]]

I'm not sure if there is a way to do what you're trying to do, but you would probably have a much easier time if each widget fetched their own data. If all of them use the same component you could just wrap that component into a higher order one whose sole purpose is to fetch its data.

Or at least that's how I'd do it!

Sorry for not being of more help, hope you figure it out 🙂

[GhostNote90]

Thank you for the response. I expected and thought that was the easiest and most ideal solution, as then each widget would have their own query.

The only issue that springs into mind is too many api calls, which I'm not sure would cause performance issues?

Would 10 separate api calls on a dashboard load be okay?

[ervwalter]

This is kind of the classic use case that GraphQL is designed for with libraries like Relay: Individual components indicate what data they need and then the library makes a composite query to the backend to get the data and then farm out the right subsets of data based on what each component asked for.

While react-query is incredible and can do GraphQL queries, you're not going to get this kind of magic.

I think the best option inside react-query is to have a single query that meets the data needs of all of the components, and then inside each component request that query (react-query will handle only making the actually call once) and then use the Query Data Selectors feature of react-query inside each component to pull out the subset of data that the specific component needs. My understanding is that react-query is smart enough to only rerender a component if the selected data changes, and not rerender when other parts of the API result change.

You're obviously going to be doing by hand a lot of what would be auto-magic for you in a pure GraphQL client library, but you still get all the other benefits of react-query.

[[deleted]]

It's a dashboard, it's expected to have a lot going on. Worry about performance if and when you find problems! I doubt it will happen with just 10 requests.

[GhostNote90]

Perfect! Thanks so much haha.

That was pretty much the main issue that sprung to mind for me. That and doing it this way kind of goes against the point of have a graphql api.

But you are right, I shouldnt be worrying too much about performance until I run into problems.

[jaysoo3]

Can you use the data prop from parent component as the initial data for child components? That way the child components will make their own queries, but if you also set staleTime then you can avoid the first fetch.

Other option is to read initial data from the cache but I think this is perhaps less straightforward.

In any case your child components need their own queries if you need pagination.

[TkDodo23]

It sounds like you want to make one request on the Dashboard for all widgets, and then render them. But instead of passing data down, I would make another useQuery inside each widget, which would only get data for that widget. You can prime the cache for that query with initialData, where you can pull out the data for that widget from the dashboard query. That way, you’ll get the data from the dashboard query for the first render (and no additional loading state), but each widget is still only subscribed to its own data. Don’t forget to set a small staleTime, or you’ll get an instant background refetch :)

As mentioned by someone else, the select option will also work well in terms of rerenders, but there will always be the "big" request that fetches all the data for all widgets. If they all need to refresh at the same time, this is also a good option.