message: (docs) - update docs to reflect us reducing the resolve methods to a single one
diff: @@ -57,21 +57,19 @@ A resolver gets four arguments:
  - parent: in this case the result of the `Todo` up until us getting `text`
  - arguments: the arguments used in this field.
  -- cache: this is the normalised cache, there are three methods exposed to use
  - in custom resolvers. These will be explained in detail later.
  +- cache: this is the normalised cache, this cache provides us with a `resolve` method
  + more about this underneath.
  - info: contains the fragments used in the query and the variables in the query.
  -Now for the methods in the cache, we have two methods `resolveProperty` and
  -`resolveEntity`. The property method accepts three arguments in this order
  -`parent` passed to your original resolver just pass it through, the `field`
  -you are looking for this is allowed to be a relation it will get resolved and
  -optionally some arguments for the field.
  -`resolveEntity` accepts one argument, this is an object with one required property
  -and two optional (one should be used). The required property is called `__typename`
  -and indicates the entity you are looking for, let's go with our previous example and
  -consider this as `Todo`, the two optional arguments are `id` and `_id` these are used
  -to see what specific `Todo` we are looking for.
  +The `cache.resolve` method is used to get links and property values from the cache,
  +our cache methods has three arguments:
  +- entity: this can either be an object containing a `__typename` and an `id` or `_id`.
  + This argument however can also be a string, this will be a key leading to a cached entity.
  +- field: the field you want data for, this can be a relation or a single property.
  +- arguments: the arguments to include on the field.
  +
  +To get a better grasp let's look at a few examples.
  Consider the following data structure:
  ```js
  @@ -91,7 +89,7 @@ todos: [
  ];
  ```
  -When we would use `resolveProperty` to get the author it would look like this:
  +When we would use `resolve` to get the author it would look like this:
  ```js
  const parent = {
  @@ -99,23 +97,22 @@ const parent = {
  text: 'Install urql',
  complete: true,
  author: undefined,
  + __typename: 'Todo',
  };
  -const result = store.resolveProperty(parent, 'author');
  -console.log(result); // { __typename: 'Author', id: '2', name: 'Bar' }
  +const result = cache.resolve(parent, 'author');
  +console.log(result); // 'Author:2'
  ```
  -Analogue to this we could use `resolveEntity` to get this author:
  +Now we have a stringed key that indicates our author, now we
  +can use this to derive the name of our author.
  ```js
  -const entityArguments = { __typename: 'Author', id: '2' };
  -const result = store.resolveEntity(entityArguments);
  -console.log(result); // { __typename: 'Author', id: '2', name: 'Bar' }
  +const name = cache.resolve('Author:2', 'name');
  +console.log(name); // 'Bar'
  ```
  -The practical use case for a list is when for example you have a list
  -of todos and you don't want to refetch for a single Todo, then you
  -can fetch it from the already existing array instead. That way
  -your single Todo-view is always linked to its entity in the list-view.
  +This can solve practical use cases like for example date formatting,
  +you can query the date and then convert it in your resolver.
  ### updates
  @@ -124,7 +121,7 @@ incorporate that answer into the current cache, but for adding and
  deleting entities it can't really make assumptions.
  That's where updates come into play, this being the third argument
  -to our cacheExchange. Analogue to our `queryResolvers` this gets
  +to our cacheExchange. Analogue to our `resolvers` this gets
  arguments but instead of the parent argument (first one) we get the
  result of our mutation.
  