Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reinitialize streaming updates after store persist rehydration #2545

Closed
uloco opened this issue Jul 26, 2022 · 3 comments
Closed

Reinitialize streaming updates after store persist rehydration #2545

uloco opened this issue Jul 26, 2022 · 3 comments

Comments

@uloco
Copy link

uloco commented Jul 26, 2022

We are in a react native app and need to persist the api data to make it possible to use the app when being offline.
After fetching the data with a query, a graphql subscription is established to get streaming updates from the api, which will only deliver incremental changes.

I did implement this as described in the docs via onCacheEntryCreated and update the local cache accordingly with updateCachedData and this works fine for the very initial load when the store is completely empty.
But unfortunately as we persist the data, this will only be called once. When the app restarts and data gets rehydrated, the subscription will no longer trigger.

I think this is by design but really unfortunate in our scenario.

What we basically want is

  1. call the query every time the app restarts, gets in focus or reconnects to the internet. (This is somewhat working now)
  2. connect the graphql subscription when the first call succeeds.

How would you deal with this scenario?

Sidenote

I also followed your docs about Persistance and Rehydration and added the extractRehydrationInfo as described, but I am not quite sure what this does, as the whole redux state is rehydrated anyway including the whole api slice.

Though we are not using redux-persist but redux-storage, but I don't think this should matter.

We do not persist the subscriptions object in the api slice though, since this causes a memory leak increasing cache subscriptions with every restart and refetchOnMountOrArgChange not working properly.

@uloco
Copy link
Author

uloco commented Jul 26, 2022

Also I was not sure if this belonged here, but caching the subscriptions object is definitely something that sounds like a bug to me. I initially thought extractRehydrationInfo would deal with this but it didn't. Could also happen because of using another persistence library don't know...

So if you want me to move this over to StackOverflow I would be happy to do so.

@phryneas
Copy link
Member

extractRehydrationInfo restores data without the subscriptions - but nothing more. At the moment, there is no way of "restarting" a onCacheEntryCreated.

#2266 might be a good way out of this and we could also think about doing that for hydration, but for now that PR is stalling a bit.

@uloco
Copy link
Author

uloco commented Sep 5, 2022

So I managed to get the persist stuff working as you pointed out. The problem with redux-storage is, that by default you cannot specify which parts of the state are used for rehydration, it's always the whole persisted state (which in my case includes the api state).

So what I did is I wrote a custom merger function to omit the api state while merging the persisted state, but still save everything including api state in the persist store. And use extractRehydrationInfo then to rehydrate just the parts that are inside the api reducerPath. This looks like it's working as expected.

For the part about onCacheEntryAdded:
I am using onQueryStarted for now and only use the useQuery hook in a single place in the app where it gets fetched only once (onMountAndArgChange is true) In all other places of the app where I use the data I just use the useQuerySubscription hooks. (For anyone struggling with similar issues with fetch + subscription).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants