Better support for SSR errors

[rvil]

Hi,

First, I wanted to thank the community that build this library! Is one the first data fetching approaches that I really like and make sense for React and the docs are great. I am in the process of adding this library to our website (https://www.ubereats.com) and we will soon deploy to production a pilot of a single endpoint.

There's one use case the library is not able to support out of the box (and it's in the title). One good example are 404 pages, the library assumes that we want to discard errors in the server and try again in the client but a 404 will always be a 404 so it's pointless to try again in the browser. I was finally able to get this to work but I had to:

• Re-implement dehydrate so it can serialize errors in the server, we can override shouldDehydrate to something like return query.state.status === 'success' || query.state.status === 'error'; but there's no way to tweak the serialization in the dehydrateQuery function

• Re-implement hydrate so it can deserialize errors from the server:

    if (dehydratedQuery.data) {
      query.setData(dehydratedQuery.data, {
        updatedAt: dehydratedQuery.updatedAt,
      });
    } else if (dehydratedQuery.error) {
      // this is the only sketchy part since I had to use the internal dispatch function and the internal enum value
      query.dispatch({type: 3, error: dehydratedQuery.error});
    }

• I had to add initialStale: false to the query config to avoid triggering a client side fetch. This one I am guessing could by avoided in some way but it seems that this condition does not set stale to false when we are hydrating an error from the server.

I have a few ideas but I don't have context if this is something you want to support:

1. Make the breaking change to support server side rendering errors out of the box. The docs seem to point that this was a deliberate choice you made so I am guessing this is not the direction you want to go!
2. Make hydration/dehydration less opaque so applications can serialize/set errors

Let me know what you think!

[tannerlinsley]

Well, I think you’ll be happy to know that this didn’t come as a surprise and was talked about a lot when we were building the API and we have a good plan on how to fix it. We simply just didn’t want to supply that plan too early in case people ended up with different requirements. Looks like it’s time! Tanner Linsley

…

On Oct 22, 2020, 3:52 PM -0600, Ricardo Villarreal ***@***.***>, wrote: I unintentionally published a draft! It's still a WIP, will update it soon — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[rvil]

This is awesome to hear! I'll leave a link in our code to this thread so we can update our approach once there's a clean way to do it.

In the process of implementing the workaround I got familiar with the codebase so I'll be happy to contribute to the discussion, feel free to tag me if you start an RFC! (I'll subscribe to the repo too)

Thanks!

[boschni]

In V3 the entire state is dehydrated, which means you should be able to include errors by providing a custom shouldDehydrateQuery function:

// server
const state = dehydrate(client, { shouldDehydrateQuery: () => true })
const serializedState = mySerialize(state) // transform Error instances to objects

// client
const state = myDeserialize(serializedState)  // transform objects back to Error instances
hydrate(client, state)

Another approach would be to make sure query errors are always serializable:

useQuery('posts', () => fetchPosts().catch(serializeError));

[rvil]

I finally was able to play with V3 and my use case is now supported out of the box! Thanks @tannerlinsley and @boschni 🎉

I can open another discussion but I feel errors should be handled like normal responses, following the query observer logic I can see that you try to fetch every time a component mounts even if there's a cached error response because the check assumes there's a timestamp dataUpdatedAt but in the case of errors the timestamp is at errorUpdatedAt.

https://github.com/tannerlinsley/react-query/blob/db301999ffad702824b7a816eb74746d7d2e5819/src/core/queryObserver.ts#L110

Was this design intentional?