react-relay-offline useRestore & state reconciliation

[morrys]

the useRestore hook allows you to manage the restore of data persisted in the storage.
To be used if relay components are used outside of the QueryRenderer or for web applications without SSR & react-native (

const isRehydrated = useRestore(environment);
   if (!isRehydrated) {
     return <Loading />;
   }

• Example of what happens when using the useQuery/QueryRenderer without useRestore:

  • the first renderer is executed by setting the store-only policy
  • the store is empty, you will have a loading status
  • restore is resolved (https://github.com/morrys/react-relay-offline/blob/master/src/hooks/useQueryOffline.ts#L40) and forceUpdate refreshes the hook:
  • if the application is online, the original policy is used and a new execute of the QueryFetcher is performed (https://github.com/morrys/react-relay-offline/blob/master/src/hooks/useQueryOffline.ts#L59)
  • if the application is offline, the policy is still store-only and since it has not been modified, the execute is not re-executed and the application is still in a loading state. (We want to avoid it)

• Example of what happens when using the useQuery/QueryRenderer with useRestore:

  • the application shows a loading and does not render the useQuery component until it is rehydrated
  • if the application is online, the original policy is used and the execute of the QueryFetcher is performed
  • if the application is offline, the policy used will be store-only and the execute will look for the data in the store

• Example of what happens when you use the useQuery/QueryRenderer without useRestore in SSR applications:

  • the first renderer is executed by setting the store-only policy
  • the store is not empty (having initialized the store with the data recovered from the server. The data recovered from the store will be displayed
  • the state is reconciled between the initial one (recovered from the server) and the state present in the storage, this makes a notification in the store that forces the updating of all the fragments subscribed
  • the restore is resolved (https://github.com/morrys/react-relay-offline/blob/master/src/hooks/useQueryOffline.ts#L59) and the forceUpdate is not executed as data are already displayed previously (priority is given to displaying data returned by status reconciliation)

• In applications with SSR the useRestore should never be used

With the proposed change in relay-hooks, it will be possible to avoid using the useRestore as it will always be possible to perform a forced execution of the QueryFetcher.

[w01fgang]

the first renderer is executed by setting the store-only policy

If there is a non-nullable field in the query and it doesn't exist, will the application crash?

[morrys]

Hi @w01fgang,
if during the first rendered application the store is empty, the queryrender returns the same result as when the queryrender is loading

[morrys]

hi @bglgwyng,
I put the reference to your issue here which seems more appropriate to me.
For the moment I would avoid adding other components inside the library, I would prefer as soon as I have time to update the library to the latest version of relay-hooks and relay-runtime
The important thing is to understand how to use the restore and use it in the most appropriate way.
morrys/wora#138 (comment)

Thanks for the tip 💯

[bglgwyng]

I completely agree that the addition of this feature requires careful consideration.
I believe we might not even require the useRestore at all. The provided example code for restoring seems sufficient. In my opinion, the current behavior of useRestore with an updatable Relay environment (using useMemo) appears a bit buggy. This might be due to the inclusion of useState inside useRestore. Perhaps allowing programmers to handle the restore logic themselves would be clearer and result in fewer issues.