# Best practice in React regarding parent and children using the same hook to fetch data, passing the data down via props, or specific hooks **URL:** \ **Category:** Client SDKs\ **Tags:** client, web\ **Created:** [July 15, 2022, 7:02pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038 "2022-07-15T19:02:58Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Martin\_Alonso](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/martin_alonso/32/2718_2.png) [@Martin\_Alonso](https://community.apollographql.com/u/Martin_Alonso)\ **Post date:** [July 15, 2022, 7:02pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/1 "2022-07-15T19:02:58Z")
Let’s say we have a component tree in react ```auto ``` and a useTree hook that wraps a useQuery hook that fetches something like ```auto tree { specie genus leaves { shape size } trunk { bark diameter } } ``` We could call `useTree` in `` and then pass trunk and leaves data to `` and `` respectively. We could also hook `` and `` and `` with the same `useTree` hook. Given that results will be cached in the client (assuming we can cache) the performance will be ok Or we could create a `useTree`, `useTreeTrunk` and a `useTreeLeaves` hooks and the hook each component with its specific hook (and query requesting only the data it needs). What pattern is recommended by the Apollo team? Thank you ---
**Author:** ![dkempner](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/dkempner/32/2870_2.png) [@dkempner](https://community.apollographql.com/u/dkempner)\ **Post date:** [September 7, 2022, 3:26am UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/2 "2022-09-07T03:26:22Z")
It’s a good question. Personally I’m finding performance issues when I’m using too many instances of `useQuery` (in the 100s or 1000s). I haven’t found a great way to improve the performance here other than to use less `useQuery`s and use more contexts/props. ---
**Author:** ![Dylan\_Wulf](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/dylan_wulf/32/83_2.png) [@Dylan\_Wulf](https://community.apollographql.com/u/Dylan_Wulf)\ **Post date:** [September 13, 2022, 3:42pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/3 "2022-09-13T15:42:29Z")
There’s a new hook coming in v3.7 called `useFragment` which may make this easier: [Feature: useFragment hook · Issue #8236 · apollographql/apollo-client · GitHub](https://github.com/apollographql/apollo-client/issues/8236) ---
**Author:** ![swrobel](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/swrobel/32/5060_2.png) [@swrobel](https://community.apollographql.com/u/swrobel)\ **Post date:** [April 29, 2024, 7:12pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/4 "2024-04-29T19:12:51Z")
Has anyone found a way to improve this pattern using `useFragment` now that it’s available? ---
**Author:** ![JeffAuriemma](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jeffauriemma/32/2845_2.png) [@JeffAuriemma](https://community.apollographql.com/u/JeffAuriemma)\ **Post date:** [April 30, 2024, 3:48pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/5 "2024-04-30T15:48:58Z")
Hi @swrobel! I recommend checking out our Spotify Showcase for an up-to-date view of some best practices for using Apollo Client in 2024. It includes `useFragment` usage and other new APIs. > **[GitHub - apollographql/spotify-showcase: A Spotify clone that showcases the...](https://github.com/apollographql/spotify-showcase)** > > A Spotify clone that showcases the Apollo GraphQL platform. - apollographql/spotify-showcase I’ve heard of some Apollo Client users taking this one step further and using the Relay compiler with Apollo Client to compose queries from fragments, but that’s not a workflow we officially support. Does that help? ---
**Author:** ![swrobel](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/swrobel/32/5060_2.png) [@swrobel](https://community.apollographql.com/u/swrobel)\ **Post date:** [April 30, 2024, 4:10pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/6 "2024-04-30T16:10:42Z")
> [@JeffAuriemma](#): > > I’ve heard of some Apollo Client users taking this one step further and using the Relay compiler with Apollo Client to compose queries from fragments, but that’s not a workflow we officially support. Does that help? I suppose it helps in the sense that it clarifies that Apollo still doesn’t have the capability to compose queries from fragments automatically, which was an open question for me. I doubt we would go so far as to bring the Relay compiler in to bridge this gap. ---
**Author:** ![jerelmiller](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jerelmiller/32/3314_2.png) [@jerelmiller](https://community.apollographql.com/u/jerelmiller)\ **Post date:** [April 30, 2024, 4:27pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/7 "2024-04-30T16:27:00Z")
@swrobel you might be interested in the [fragment registry](https://www.apollographql.com/docs/react/data/fragments#registering-named-fragments-using-createfragmentregistry) which allows you to define fragments and reference them by name without having to use the interpolation syntax. It’s not quite what the Relay compiler does, but since Apollo doesn’t use a compiler, this is as close as you can get. You just need to ensure the fragment is registered in the fragment registry before the query is run in order for this to work. The Spotify showcase has some examples of registering fragments defined in components then referencing them by name in your queries. Hope this works for you! ---
**Author:** ![jerelmiller](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jerelmiller/32/3314_2.png) [@jerelmiller](https://community.apollographql.com/u/jerelmiller)\ **Post date:** [April 30, 2024, 4:29pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/8 "2024-04-30T16:29:56Z")
Here is an example of the fragment registry in action. [`AlbumTile` registers a fragment with the registry](https://github.com/apollographql/spotify-showcase/blob/e52b28974f04318c70c31cbef7b1df4a8600468d/client/src/components/ArtistTile.tsx#L11-L19) which is then used by the [route query](https://github.com/apollographql/spotify-showcase/blob/e52b28974f04318c70c31cbef7b1df4a8600468d/client/src/routes/artists/artist.tsx#L44) by name. ---
**Author:** ![swrobel](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/swrobel/32/5060_2.png) [@swrobel](https://community.apollographql.com/u/swrobel)\ **Post date:** [April 30, 2024, 4:53pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/9 "2024-04-30T16:53:31Z")
Thanks so much for the replies! I’ve read the comments in [useSavedTracksContains](https://github.com/apollographql/spotify-showcase/blob/91fac7271ec4ec5429e5e96efa989601ecbce0a2/client/src/hooks/useSavedTracksContains.ts) several times, and I still don’t understand the pattern of utilizing `useBackgroundQuery` and `useFragment` in the same file. Is the `useFragment` basically there to read all of the batches present in the cache as they come in? ---
**Author:** ![jerelmiller](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jerelmiller/32/3314_2.png) [@jerelmiller](https://community.apollographql.com/u/jerelmiller)\ **Post date:** [May 1, 2024, 3:09pm UTC](https://community.apollographql.com/t/best-practice-in-react-regarding-parent-and-children-using-the-same-hook-to-fetch-data-passing-the-data-down-via-props-or-specific-hooks/4038/10 "2024-05-01T15:09:51Z")
I’ll admit, that one is a bit of an odd duck but I can provide some context there (and perhaps this is a good opportunity for me to update the comments to make it even clearer!) The idea behind that hook is that if I have a large playlist, I want to be able to determine which of those playlist items are actually “liked”. Spotify’s API only allows us to load 50 items at a time, so large playlists present a problem because I need to slice up the list of ids into 50-length batches and request those. `useBackgroundQuery` is doing the work to load the initial 50 items because I want to kick that off in render rather than `useEffect`, then I load the rest of the batches via `client.query(...)`. The `useFragment` is there to handle cache updates so that I can return the entire set of results without having to sync that state to my own `useState` (potentially getting out of sync). This is also useful in case I already have that data in the cache as I don’t need to run my own `cache.readFragment` to get the initial set of results. To be honest, I’m not entirely sure if `useBackgroundQuery` is necessary here, and as I’m thinking about this, its auto dispose behavior may actually work against me. I’ll need to explore that a bit more. Hope this helps provide some context!