Profiles to React Queries #633
Conversation
Why? Right now zustand is being used to manage the network state of profiles We refresh profiles whenever a new group is added/new conversation/group is refreshed Theres some potential issues: Groups can get large Conversation lists can get large New and interesting ways of using profiles in the app may be added (group invites for example) These require adding additional checks if we should update the profiles etc. What happens when a request fails? What happens if members change? As we move towards open source it can be helpful to devs to have more consumable hooks, rather than tracking down exactly where the data is coming from and why it's refreshing/cached/missing With React Query we get better out of the box retries, and can use a batching and deduplicating library to manage this for us The main goal of this is that incase anything gets missed, we can have a foolproof fallback to refresh just in case
alexrisch
force-pushed
the
ar/refactor-profiles
branch
from
425b6db to
e0dadc6
Compare
alexrisch
changed the title
alexrisch
changed the title
| const profileSocials = create({ | ||
| fetcher: async (addresses: string[]) => { | ||
| const data = await getProfilesForAddresses(addresses); | ||
| return data; | ||
| }, | ||
| resolver: indexedResolver(), | ||
| scheduler: windowedFiniteBatchScheduler({ | ||
| windowMs: 10, | ||
| maxBatchSize: 150, | ||
| }), | ||
| }); |
There was a problem hiding this comment.
I think react-query handle request deduplication
There was a problem hiding this comment.
It does, but this helps with batching all requests
Example I am fetching profile A, B, C it will do all of those requests
Docs: https://tanstack.com/query/v4/docs/framework/react/community/batching-requests-using-bathshit#implementation
There was a problem hiding this comment.
OH very nice yeah makes sense didn't know about this
|
|
||
| export const profileSocialsQueryKey = ( | ||
| account: string, | ||
| peerAddress: string | ||
| ) => [QueryKeys.PROFILE_SOCIALS, account, peerAddress]; |
There was a problem hiding this comment.
Curious, why did you choose to add all keys into 1 file? Just really curious. I'm not doing that but maybe it's the best practice. What I do is put each keys into it's own file
There was a problem hiding this comment.
I just kinda did it one day, but I think how we are structuring folders by feature it probably makes more sense to split them into the separate files
There was a problem hiding this comment.
Love that! Big fan of react-query. Would just make sure that it's aligned with how @technoplato planned to integrate them so that when we go with XState we don't have to refactor a ton.
Why?
Right now zustand is being used to manage the network state of profiles We refresh profiles whenever a new group is added/new conversation/group is refreshed
Theres some potential issues:
Groups can get large
Conversation lists can get large
New and interesting ways of using profiles in the app may be added (group invites for example) These require adding additional checks if we should update the profiles etc. What happens when a request fails? What happens if members change? As we move towards open source it can be helpful to devs to have more consumable hooks, rather than tracking down exactly where the data is coming from and why it's refreshing/cached/missing
With React Query we get better out of the box retries, and can use a batching and deduplicating library to manage this for us The main goal of this is that incase anything gets missed, we can have a foolproof fallback to refresh just in case
We can further improve the usage of profiles by:
Closes #583