Idea Feedback: Apollo Elm Package

Request Feedback
9

I have added a comment on the issue. Let me know what you think.

You might be right here. I’m thinking more in terms of things like schema stitching when we combine graphql responses from different sources, though Elm does it by default as we are not treating GraphQL objects special in any way, they are just part of a big model.

Referring to GraphQL tutorial with apollo if you look at the part where their update cache.
See _updateCacheAfterVote function.
They have a model like
Link – has many – votes

const VOTE_MUTATION = gql`
  mutation VoteMutation($linkId: ID!) {
    vote(linkId: $linkId) {
      id
      link {
        votes {
          id
          user {
            id
          }
        }
      }
      user {
        id
      }
    }
  }
`

The mutation sends back the updated link already so the use case for cache here is to find and update the cache for that specific link without refetching all links. They are actually not using Apollo cache properly in this tutorial as all cache updating is not required if one changes mutation to:

const VOTE_MUTATION = gql`
  mutation VoteMutation($linkId: ID!) {
    vote(linkId: $linkId) {
      id
      link {
        id
        votes {
          id
          user {
            id
          }
        }
      }
      user {
        id
      }
    }
  }
`

It’s kinda hard to spot the difference. It’s this part:

   link {
        **id**

as soon as we add id apollo cache will automatically find all instances of link with that specific id and update them with the fields returned from this mutation. Manual cache update in this tutorial is very close to the code which one would need to write when using elm-graphql package.
Not sure it fits with Elm philosophy, having explicit updateCache(link) would still work for me to be honest. Trying to find all entries of that specific Link manually in a multi-page application can get quite cumbersome and error-prone.

1 Like