getDataFromTree throws errors when any query fails

[choonkending]

Background

I asked a question on StackOverflow today here.

I thunk about it harder afterwards and decided that this is a discussion worthy of a Git issue.

Problem

Any error gets thrown in getDataFromTree.

Expected/Proposed Behaviour

Return the data with an error Array, without throwing an error.

Why?

Our GraphQL server speaks to multiple APIs and returns a graphQL response which is handled by Apollo UI.

Certain GraphQL errors are not considered critical, and we want to still render a page with it. E.g.

data: {
   thing: {
       id: "1234"
       name: "Thing"
       nonCriticalData: null
   },
   error: {
       graphQLErrors: [
           path: ['thing', 'nonCriticalData']
       ]
   }

With the above response we get from apollo, we want to still render a page with thing.

I have followed #488 (comment) and got to this point.

In my mind the errors should be returned and not thrown unless necessary, because not all errors are equal.

Ideally I would like to do the following

getDataFromTree(app)
    .then(() => {
             const content = ReactDOMServer.renderToString(app);
             const { data } = client.getInitialState();   <------ Data (with errors)
             // check for expected errors and render
             return renderPage(data);
     })
    .catch(error => {
         // handle unexpected errors
    });

Version

• apollo-client@1.0.0-rc2
• react-apollo@1.0.1

P.S. Thanks for an awesome library. Happy to help out if needed.

[helfer]

Hey @choonkending, sorry it took me so long to get around this issue. I agree with you 100% that this behavior isn't consistent, but because of the way server side rendering is implemented, we can't easily change it to do what you want. The reason is that the queries are all executed in a first pass on the route, then their data is stored in the cache. When you call renderToStringWithData, the data from the cache is used to render the tree synchronously. We don't cache errors, so there's currently no easy way to change this without either changing the way server side rendering works (make it asynchronous), or changing the way errors are handled in the store. Even if the rendering were identical on the server and the client given the same query, the initial react render on the client would be unaware of the errors (because they're not stored), so there would be an inconsistency there. 🙁

We're planning improvements in the next version of the API that would make this problem go away, but for the moment I think it's quite difficult to change.

If you're very interested and motivated to work on this problem, just let me know, we could definitely use the help!

[choonkending]

@helfer No worries! Thanks for getting back to us.

If you're very interested and motivated to work on this problem, just let me know, we could definitely use the help!

Definitely.

Just to get a better understanding:

• How does the caching model work? Can you point us to parts of the codebase where you think this is the tricky part to change?
• Are there any docs/git issues around the thinking for the next version of the API?

[helfer]

@choonkending the cache normalizes all data, and when you run a query against the cache, the result is assembled from the normalized parts. That's a problem if errors don't have paths, because then there's no way to know which field an error is associated with, and no way to know if an error should be returned with the query run against the cache.

There's no discussion issue yet for the next version of the API, but I'm trying to put an initial post together soon. In the meantime, I think the best thing to do would be to write a use-case for each requirement that we can think of. Having SSR be consistent with client rendering is one use-case, and I think we should write that down and document it well, so we can have a discussion around it.

For that purpose, could you add a comment here, please? #519

You should also feel free to write down other use-cases that haven't been mentioned yet (so far there are very few, I'm hoping people will add more to it, even current functionality of react-apollo that they are relying on).

[jbaxleyiii]

This really needs to be talked through and fixed 💪 After I clean up the tests and add better typings. I'll try to get around to error handling and SSR!

[Dattaya]

Just want to leave a comment in support of @choonkending proposal. I already handle errors in components that perform queries: if {props.data.error} return a component that shows the error's message (I'm talking about errors that are thrown from resolvers/connectors). So I expect the server to render the exact result that would be rendered on the client. I tried to use a workaround suggested in #488 (comment) but it doesn't really work, because apolloClient.getInitialState() returns a data object without an error.

[OllieJennings]

I would just like to say that this has become a big issue for me.

As my app has gotten more complex, i have gone down the route of having 2 bundles, and if a 404 then rendering 2nd bundle, and losing the SPA benefits.

If you could still keep query errors in state, and allow SSR of 404 pages, it would simply things massively

[edoroshenko]

Hi @helfer

If you're very interested and motivated to work on this problem, just let me know, we could definitely use the help!

I'm very interested and motivated (as long as it's my impediment).
Could you let me know if you already started approaching this problem? If no, do you have some thoughts how you would approach it?

[helfer]

Hi @edoroshenko. That's awesome. @jbaxleyiii can probably tell you more about it since he designed it together with Tom and is now working on Apollo full time!

[edoroshenko]

Thanks @helfer!
Do you guys have a slack channel or what is the best way to communicate?

[jbaxleyiii]

@edoroshenko you bet! Check out http://dev.apollodata.com/community/ and join us on slack! I'd be happy to work together on finally bringing some better error support to Apollo and SSR in general!