Evaluate using react-query QueryClient in `useGetQueryResultBundle`
This would likely be a simple candidate to change to use the react-query library, since it's used in a few different components, and we gave the hook an API that is very similar to react-query's useQuery API.
Not sure if we would see huge performance gains in terms of automatic re-fetching, since these typically run queries with results that don't change. We may see benefits if these resources are often re-fetched e.g. as a user navigates through a Portal.
In both this issue and PORTALS-1861, we would want to come up with a generalizable solution for dealing with asynchronous jobs compatible with the Synapse API.
Verified that react-query is being used. Very cool:
What do you think about increasing the default staleTime from 30s to something much larger, say a day? My thinking is that consumers want the pages to load asap.
Could curators, who want to verify their most recent change, just reload the page to see the latest data (if thestaleTime was significantly increased)?
Perhaps to validate this in a 'production' deployment (e.g. sage-bionetworks.github.io/Synapse-React-Client), find a component that uses the hook (e.g. Goals), open your browser network tools, wait 30 seconds or so, unfocus/refocus the window, and see if the QueryBundle network requests re-fetch.
I think this would be easier to validate in dev, where you could insert the react-query devtools into the new wrapper. Open the styleguide locally and verify that requests for a few of the homepage components show up in the react-query devtools pane.
is using this in the latest Entity Finder work.