How do I get the original returned object in a resolver?

[Svarto]

Hi,
I am struggling getting the original query response when using resolvers. When I see what the "parent" object contains, it for some reason does not contain the property which I am referring to in the resolver.

In this example, trying to follow the docs, I only want to pass the exact same object I receive from the GraphQL API to the frontend - with a console.log firing in the resolver (once I get that working I will start to manipulate the values, but this is just trying to get the basics working).

Would really appreciate some help as I am struggling for some reason...

Resolvers:

export const CacheExchange = cacheExchange({
  resolvers: {
    recipe: {
      recipe_ingredients(parent, args, cache, info) {
        console.log("QUERY CLIENT FIRED", parent);
        return parent.recipe_ingredients;
      },
    },
  },
})

GraphQL query (shortened to relevant bits):

export const GET_RECIPE_DETAILS = gql`
  query GetRecipeDetails($id: Int!) {
    recipe_by_pk(id: $id) {
      __typename
      id
      title
      recipe_ingredients(order_by: { order: asc }) {
        __typename
        id
        order
        details
        measure
        amount
        section
        ingredient {
          __typename
          name
        }
        recipe_ingredients_images {
          __typename
          id
          filename
          folder
          height
          width
          user_id
          token
          image_order
        }
      }
    }
  }
`;

When this query fires, the console.log correctly shows but the parent object does not actually contains the "recipe_ingredients" property I am referring to so the resolver returns undefined - crashing the app.

console.log response:

QUERY CLIENT FIRED Object {
  "__typename": "recipe",
  "id": 648,
  "title": "Angel cake",
}

Any ideas what could potentially be wrong here? Do I need to do something with the args as the recipe_ingredients property is ordered on the backend (just guessing here)

[kitten]

The docs do mention this around here: https://formidable.com/open-source/urql/docs/graphcache/computed-queries/#resolve
I haven't quite looked at the specific line to link to but the tl;dr is that parent is only the object as it's been assembled to from previous fields. So you don't want to use it directly most of the time. The explanation for that is simple: Any entity has a potential countless number of fields, some even taking arguments. The cache structure is an implementation detail so it's not possible to return all that the cache has in a meaningful form.

Do you have some details on what you're trying to achieve? I see that you want to basically write cache.resolve(parent, 'recipe_ingredients', args). However that wouldn't change the default behaviour as it would just resolve that relation as it would if that resolver wasn't there 😅

[Svarto]

@kitten thanks!

I see, so if I understand what you are saying, the flow of data is actually API > Cache > Frontend, and the resolver intercepts the data between Cache & Frontend (i.e. API > Cache > Resolver > Frontend)? I was thinking querying the cache would return null, as the resolver gets called before the cache has been populated from the API query.

I am trying to basically flatten a field in the recipe_ingredients object, so that
export const GET_RECIPE_DETAILS = gql`

  query GetRecipeDetails($id: Int!) {
    recipe_by_pk(id: $id) {
      recipe_ingredients(order_by: { order: asc }) {
        id
        ingredient {
          __typename
          name
        }
      }
    }
  }
`;

Is flattened into:

  query GetRecipeDetails($id: Int!) {
    recipe_by_pk(id: $id) {
      recipe_ingredients(order_by: { order: asc }) {
        id
        name
      }
    }
  }
`;

I am doing this as the entire frontend is written assuming the name object is without nesting, and now with a backend change I either have to find a way to use a resolver to maintain the previous data structure, or rewrite a lot of frontend code to reflect the backend change :)

I see, so the cache.resolve actually returns a reference, and this is then passed back through the resolver. As I want to edit the data, would you recommend me to use a cache.readFragment, modify the data and return it or is there a better way to do it?

The function to flatten the ingredient names is the following (for your reference):

export function flattenIngredientNames(ingredients) {
  let flattenIngredients = [];

  if (ingredients.length == 0) {
    flattenIngredients.push({ ...constantData.recipe_ingredients[0] });
  } else {
    for (let ingredient of ingredients) {
      flattenIngredients.push({
        ...ingredient,
        name: ingredient.ingredient.name,
      });
    }
  }

  return flattenIngredients;
}

[JoviDeCroock]

This is not possible, your query will still look like:

  query GetRecipeDetails($id: Int!) {
    recipe_by_pk(id: $id) {
      recipe_ingredients(order_by: { order: asc }) {
        id
        ingredient {
          __typename
          name
        }
      }
    }
  }

Which means we'll follow this shape, adding client-side extensions to the server-side schema is not supported. GraphCache aims to be a client-side representation of your server-side state. Resolvers can be used to concatenate paginated queries, format data-fields, ... it isn't used to arbitrarly create fields that aren't there, this can break subsequent updates.

[kitten]

To follow up on this. It's certainly possible to get this data and would look like this:

cache.resolve(parent, 'recipe_ingredients', args)
  .map(child => child.resolve(child, 'ingredient');

This would skip that connection but it won't work. In GraphQL we expect data in the shape of the query document.

Regardless of the cache or Graphcache, this cannot be altered because the query doesn't contain any information on skipping that connection.

This leads to another conclusion that this seems like a UI convenience. If your UI needs the data in a different form then you can map it there, for instance with useMemo in React, I mean.

But the deeper reasoning here is that as long as you control the GraphQL schema then the schema needs to provide the best case shape for what your UI requires and should be altered if it doesn't. Given that this is an example I won't read into it too much but this seems like a minor "convenience change" to me which adds some indeterminism to what's usually deterministic: data shapes in GraphQL follow the schema.

To also mention what else can be considered here:

• type generation would be out of the question if the shape didn't follow the schema
• Graphcache specifically is a GraphQL cache, so it doesn't arbitrarily alter data because it can't traverse unknown structures.
• A separate exchange could alter this but would either have to traverse and skip over parts of the query document manually or would have to just map the data and disregard the query (hence this is more of a UI task)
• while with resolvers you can somewhat alter the data, you can't alter the query. Think of it like this; the API / GraphQL execution can't alter the query document either once the user has sent it

[Svarto]

@JoviDeCroock @kitten thank you both for spending the time to respond and share your knowledge. Makes sense and I will look into another way of managing this in the app. Thank you!!

[kitten]

I also want to leave an explanation here separately regarding this:

I am struggling getting the original query response when using resolvers. When I see what the "parent" object contains, it for some reason does not contain the property which I am referring to in the resolver.

I've previously mentioned that resolvers receive a parent object which is the object of the query being assembled progressively. I haven't explained why that is however.

One the one hand, this object can never be the original part of the query response at that place for two reasons. The cache won't have access to it anymore by the time it's reading a query. Caching data and reading it back are two separate processes. A normalised cache handles any query so it never retains access to the original data after writing it to the cache, so therefore the resolvers won't receive it either; because it may be any given query if we went by the original data, which doesn't match the query that's currently read from cache. In other words: For any given query and response from the server, there are multiple queries and responses that the cache can then assemble, independent of the query that has actually been sent to the API. That's why reading and writing are independent.

So the other question then is, why is the parent object not the data as the query document dictates. That's because of a small choice: Do resolvers hook into the process of traversing a query or do they run afterwards? The reason why they must run during the traversal/reading process and not after the whole subtree of the query document has been assembled already is because a resolver may alter the result drastically. It can give entire hints of what parts of the query link to and return IDs to other entities. This means that we can't defer it (and hence parent will always be incomplete) because it can't be run at any later point. The parent would also be highly consistent either way since, again, the queries that can be run can have a countless number of different selection sets, so you can never rely on a specific field being on it already.