|
1 | 1 | ---
|
2 |
| -title: Controlling the Cache |
| 2 | +title: Controlling the Store |
3 | 3 | order: 13
|
4 | 4 | ---
|
5 | 5 |
|
6 | 6 | Apollo performs two important core tasks: executing queries and mutations, and caching the results.
|
7 | 7 |
|
8 |
| -Thanks to Apollo's cache, it's possible for the results of a query or mutation to affect to your UI in all the relevant places . In many cases it's possible for that to happen automatically, whereas in others you need to help the client out a little in doing so. |
| 8 | +Thanks to Apollo's store, it's possible for the results of a query or mutation to alter to your UI in all the relevant places. In many cases it's possible for that to happen automatically, whereas in others you need to help the client out a little in doing so. |
9 | 9 |
|
10 | 10 | <h2 id="dataIdFromObject">Using `dataIdFromObject`</h2>
|
11 | 11 |
|
12 |
| -Apollo's cache is [constructed](http://dev.apollodata.com/core/how-it-works.html#normalize) one object at time, based on an id generated from each object returned by your queries. |
| 12 | +Apollo's store is [constructed](http://dev.apollodata.com/core/how-it-works.html#normalize) one object at time, based on an ID generated from each object returned by your queries. |
13 | 13 |
|
14 |
| -By default, Apollo cannot determine the ids to use for object except through the position that they take in queries. However, if you specify a function to generate an id from each object, and supply it as the `dataIdFromObject` in the [`ApolloClient` constructor](initialization.html#creating-client), you can create an unique id for each "real" object. |
| 14 | +By default, Apollo cannot determine the IDs to use for object except through the position that they take in queries. However, if you specify a function to generate an ID from each object, and supply it as the `dataIdFromObject` in the [`ApolloClient` constructor](initialization.html#creating-client), you can create an unique ID for each "real" object. |
15 | 15 |
|
16 | 16 | ```js
|
17 | 17 | import ApolloClient from 'apollo-client';
|
18 | 18 |
|
19 |
| -// If your database has unique ids across all types of objects, you can use |
| 19 | +// If your database has unique IDs across all types of objects, you can use |
20 | 20 | // a very simple function!
|
21 |
| -// Remember: You'll need to ensure that you select ids in every query |
| 21 | +// Remember: You'll need to ensure that you select IDs in every query |
22 | 22 | const client = new ApolloClient({
|
23 | 23 | dataIdFromObject: o => o.id
|
24 | 24 | });
|
25 | 25 |
|
26 |
| -// If the ids are only unique per type (this is typical if an id is just an |
27 |
| -// id out of a database table), you can use the `__typename` field to scope it. |
| 26 | +// If the IDs are only unique per type (this is typical if an ID is just an |
| 27 | +// ID out of a database table), you can use the `__typename` field to scope it. |
28 | 28 | // This is a GraphQL field that's automatically available, but you do need
|
29 | 29 | // to query for it also.
|
30 | 30 | const client = new ApolloClient({
|
31 | 31 | dataIdFromObject: o => `${o.__typename}-${o.id},`
|
32 | 32 | });
|
33 | 33 | ```
|
34 | 34 |
|
35 |
| -These ids allow Apollo Client to reactively tell your queries about updates when new information becomes available. |
| 35 | +These IDs allow Apollo Client to reactively tell your queries about updates when new information becomes available. |
36 | 36 |
|
37 |
| -In some cases, just using `dataIdFromObject` is not enough for your application UI to get these updates, as such id-based updates can only affect documents that are already matching a given query. |
| 37 | +In some cases, just using `dataIdFromObject` is not enough for your application UI to get these updates, as such ID-based updates can only affect documents that are already matching a given query. |
38 | 38 |
|
39 | 39 | For example, if you want to add something to a list of objects without refetching the entire list, or if there are some objects that you can't assign an object identifier to, Apollo Client cannot update existing queries for you. In those cases you have to use `fetchMore` in order to make sure that the queries on your page are updated with the right information and your UI updates correctly.
|
40 | 40 |
|
@@ -101,7 +101,7 @@ Although `fetchMore` is often used for pagination, there are many other cases in
|
101 | 101 |
|
102 | 102 | <h2 id="updateQueries">Using `updateQueries`</h2>
|
103 | 103 |
|
104 |
| -Just as `fetchMore` allows you to update your UI according to the result of a query, `updateQueries` lets you update your UI based on the result of a mutation. To re-emphasize: most of the time, your UI should just update automatically based on the result of a mutation as long as modified fields of objects and the object identifiers of modified objects are returned with the mutation (see the cache and `dataIdFromObject` documentation for more information). |
| 104 | +Just as `fetchMore` allows you to update your UI according to the result of a query, `updateQueries` lets you update your UI based on the result of a mutation. To re-emphasize: most of the time, your UI should just update automatically based on the result of a mutation as long as modified fields of objects and the object identifiers of modified objects are returned with the mutation (see the [`dataIdFromObject`](#dataIdFromObject) documentation above for more information). |
105 | 105 |
|
106 | 106 | However, if you are removing or adding items to a list with a mutation or can't assign object identifiers to some of your objects, you'll have to use `updateQueries` to make sure that your UI reflects the change correctly.
|
107 | 107 |
|
|
0 commit comments