Hacker News new | ask | show | jobs
by gorgonian 2582 days ago
I agree with other commenters that Apollo is too big and too opaque to easily understand. The docs don’t have enough examples and are out of date in some places (see link-state). I’ve had a lot of confusion while trying to implement Apollo in my current react project.

I’ve also seen some erratic behavior from Apollo. While testing I found that Apollo deduplicates queries too aggressively. I made some mutations with slightly different inputs (think naming a new item “a” and another one “b”) and several of them would not get sent. In my example it would have resulted in two new items on the server but instead only one was created, because the second mutation wasn’t sent.

I also found that using the `called` flag in a mutation function child was basically useless because sometimes it would be false even if the mutation went through. I switched to using the onCompleted prop in the component and that’s worked.

Another thing I ran in to is that Apollo sometimes can’t update the store because I sent a query without an ID field. It throws an error. If an ID is required for all queries the docs should say so.

Also I don’t think the docs say that you should return any fields you update in a mutation, to make sure the store is current. I think I found that out on stack overflow.

2 comments

> If an ID is required for all queries the docs should say so.

they absolutely should. It's not really needed every time, but when you have a queries with IDs and without-that's when the cache blows up. They even a have a snapshot test for this unfortunate behavior: https://github.com/apollographql/apollo-client/blob/master/p...

Deduplication shouldn’t work on mutations at all! There has got to be something else wrong. If I were to guess, it’s probably an issue with the Apollo React interface.

Also IDs aren’t required for cache updates, only the typename.

> Also IDs aren’t required for cache updates, only the typename.

this is very inacurate. The problem happens when an items is cached with an ID and then another GraphQL request tries to cache it without and ID or vice versa. This is where the apollo-cache-inmemory blows up with an error like this: https://api.media.atlassian.com/file/f82c0ee8-2412-4f1b-8027...

There's even a test for this unfortunate behavior: https://github.com/apollographql/apollo-client/blob/master/p...