apollo-client: Components never get updated after `writeData` or `writeQuery`

Intended outcome: Components update automatically after cache modification with writeData or writeQuery. You repeat it everywhere in your docs:

Any subscriber to the Apollo Client store will instantly see this update and render new UI accordingly.

Actual outcome: Components never get updated after writeData or writeQuery.

You have to call broadcastQueries() like so:

this.props.client.queryManager.broadcastQueries();

in order to force your <Query> tags to reload themselves to render your new cache data. But after you call broadcastQueries() a new issue arise - it reloads ALL your <Query> tags, not just those that you need. Huge performance issue.

ANd you have nothing in your docs about it. Question here

How to reproduce the issue:

class FooComponent extends PureComponent {
  
  componentDidMount() {
    
    const query = gql`
      query QQQ {
        Me {
          __typename
          id
          something
        }
      }
    `;
    
    // I call writeQuery manually
    // How does <Text> input change instantly with new value?  
    // Or change it to writeData
    this.props.client.cache.writeQuery({
      query: query,
      data: {
        Me: {
          __typename: 'User',
          id: 'be2ae9d718c9',
          something: 'ABSDEF'
        }
      }
    });
  }
  
  render() {
    
    let something = this.props.Something.something;
    
    // How does <Text> input change instantly with new value 
    // after I call writeQuery in componentDidMount above?
    return (
      <View>
        {/* HOW DOES IT CHANGE instantly after writeQuery or writeData ?? */}
<Query query={ GET_SOMETHING }>
      { params => {
        const data = get(params, 'data.Me.something', {}) || {};
        const something = data.something;
        return (
          <Text>
            {something}
          </Text>
        )
      } }
    </Query>
      </View>
    )
  }
}

export default compose(
  withApollo,
  graphql(getSomethingQuery, {
    name: 'Something'
  }),
)(FooComponent);

Versions

  System:
    OS: macOS High Sierra 10.13.4
  Binaries:
    Node: 8.11.3 - /usr/local/bin/node
    npm: 5.6.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 68.0.3440.106
    Safari: 11.1
  npmPackages:
    apollo-boost: ^0.1.4 => 0.1.10 
    apollo-cache-inmemory: ^1.1.0 => 1.2.5 
    apollo-client: ^2.0.3 => 2.3.5 
    apollo-link: ^1.0.3 => 1.2.2 
    apollo-link-http: ^1.2.0 => 1.5.4 
    react-apollo: ^2.1.1 => 2.1.9 

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 63
  • Comments: 66 (5 by maintainers)

Most upvoted comments

any update on this? Just came across the same problem and it’s rather frustrating

you need to use another instance of the data object like this

update: (proxy, { data: { createTodo } }) => {
      const data = _.cloneDeep(proxy.readQuery({ query }));
      data.todos.push(createTodo);
      proxy.writeQuery({ query, data });
    },

@wzup, This was happening to me and I (think) I fixed it by using client.writeQuery instead of client.cache.writeQuery. I’m not sure what the difference between these two functions is - but when I use the former, the rest of the components are updated with the new, written results.

I was just tearing my hair out over a regression where an existing component doesn’t consistently update anymore after a mutation call, update : writeQuery.

I tested render, and it appears not to receive new props after a writeQuery from the mutation update even though the cache seems to be right (but sometimes it does work).

I played around a bit and was relieved (and confused) to see it behaving properly and consistently after some very minor changes making the data write immutable. Here’s some examples:

Bad, flaky component re-rendering:

      update: (cache, { data: { createFieldMapping } }) => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        data.fieldMappings.push(createFieldMapping);
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data,
        });
      },

These very minor changes (can you spot them?) made the mutation update work flawlessly again:

      update: (cache, { data: { createFieldMapping } }) => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data: { fieldMappings: [...data.fieldMappings, createFieldMapping] },
        });
      },

Seems like it has something to do with immutability.

Here’s another example with writing for a delete mutation:

Not updating after mutating:

      update: cache => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        data.fieldMappings = data.fieldMappings.filter(o => o.id !== id);
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data,
        });
      },

Works again:

      update: cache => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data: {
            fieldMappings: data.fieldMappings.filter(o => o.id !== id),
          },
        });
      },

So I’m pretty confused about why this works, but I’m hoping this account helps someone else or helps Apollo fix a bug.

Having similar problems. I observe the cache is updated, but a component that directly uses the Query does not re-render. client.queryManager.broadcastQueries(); does not help

Wow… this is a really really really poorly documented issue in Apollo.

If anyone is using hooks there is a change that you need to add the { returnPartialData: true } option to the useQuery call on the dependant item containing the list. Check the API docs

  const { data, ...rest } = useQuery(SOME_QUERY, {
    variables: { uuid },
    returnPartialData: true
  });

One comment i will make about Apollo, its documentation is very poor. Time and time again i see so many developers struggling with simple issues that are due to a lack of documentation. Otherwise its an amazing library.

Short answer: just use client.writeQuery instead of cache.writeQuery when you want your changes to be reflected in the UI immediately.

Long answer (from docs):

  1. The cache you created with new InMemoryCache(...) class is not meant to be used directly, but passed to the ApolloClient constructor. The client then accesses the cache using methods like readQuery and writeQuery. The difference between cache.writeQuery and client.writeQuery is that the client version also performs a broadcast after writing to the cache. This broadcast ensures your data is refreshed in the view layer after the client.writeQuery operation. If you only use cache.writeQuery, the changes may not be immediately reflected in the view layer. This behavior is sometimes useful in scenarios where you want to perform multiple cache writes without immediately updating the view layer.

  2. The update function receives cache rather than client as its first parameter. This cache is typically an instance of InMemoryCache, as supplied to the ApolloClient constructor whent the client was created. In case of the update function, when you call cache.writeQuery, the update internally calls broadcastQueries, so queries listening to the changes will update. However, this behavior of broadcasting changes after cache.writeQuery happens only with the update function. Anywhere else, cache.writeQuery would just write to the cache, and the changes would not be immediately broadcast to the view layer. To avoid this confusion, prefer client.writeQuery when writing to cache.

Source: https://github.com/apollographql/apollo-client/pull/4664/files

I was having the same issue. After reading @good-idea 's comment, I replaced client.cache.writeQuery with client.writeQuery and it started to work on my HOC (withApollo component).

Hmm, not sure that I have a similar issue. But, when I put writeData to setTimeout it works correctly:

<ApolloConsumer>
  {client => {
    const navbarState: State = {
      header,
      backPath: backPath || "",
      caption: caption || "",
      __typename: "Navbar"
    };

    setTimeout(() => {
      // Not sure why, but without setTimeout
      // NavbarContainer doesn't get updated
      client.writeData({ data: { navbar: navbarState } });
    }, 0);

    return null;
  }}
</ApolloConsumer>

Other components are updated correctly with new state from writeData

For me, I had to include variables into the query:

const MEAL_COMPONENTS = gql`
  query MealComponents($active: Boolean) {
    mealComponents(active: $active) {
      id
      name
      sensitivityInformation {
        id
        sensitivityName
        present
      }
    }
  }
`;
const MEAL_COMPONENTS_SUBSCRIPTION = gql`
  subscription Meals {
    mealComponentsSubscription {
      id
      name
      active
      sensitivityInformation {
        id
        present
        sensitivityName
      }
    }
  }
`;
  useSubscription({
    subscription: MEAL_COMPONENTS_SUBSCRIPTION,
    variables: {},
    onSubscriptionData: ({ client, subscriptionData }) => {
      setNewMealToCheck(true);

      client.cache.writeQuery({
        query: MEAL_COMPONENTS,
       // You need to add any variables the query makes here:
        variables: { active: true },
        data: { mealComponents: subscriptionData.data.mealComponentsSubscription },
      });
    },

Query component data updated works after added corresponding variables options either on client.writeQuery or client.cache.writeQuery.

Query componen t

<Query query={POSTS} variables={{ limit: 5, offset: 0 }}>
{({ data }) => (
            {JSON.stringify(data)}
)}
</Query>

withApollo wrapped component

data will NOT get updated

const { client = {} } = props;
      const { posts = [] } = client.cache.readQuery({
        query: POSTS,
        variables: { limit: 5, offset: 0 },
      });
      const { data: { post = {} } = {} } = await client.query({
        query: POST,
        variables: { id: postId },
      });
      client.cache.writeQuery({
        query: POSTS,
        data: { posts: [post, ...posts] },
      });

data UPDATE WORKS!!

const { client = {} } = props;
      const { posts = [] } = client.cache.readQuery({
        query: POSTS,
        variables: { limit: 5, offset: 0 },
      });
      const { data: { post = {} } = {} } = await client.query({
        query: POST,
        variables: { id: postId },
      });
      //client.writeQuery works as well
      client.cache.writeQuery({
        query: POSTS,
        // this variables must be added
        variables: { limit: 5, offset: 0 },
        data: { posts: [post, ...posts] },
      });
    "react-apollo": "^2.5.8",
    "apollo-boost": "^0.4.3" //    includes  apollo-cache-inmemory "^1.6.2"

@chemicalkosek When you have trouble re-rendering after an update to the cache, 9 times out of 10 the problem is caused by mutating the cached data. In this case, you’re doing data.rooms = .... If you change the first example to not modify the data from the cache, it should work:

const update = (cache, payload) => {
  const data = cache.readQuery({ query: ALL_ROOMS_QUERY });
  const newRooms = data.rooms.filter(
    room => room.id !== payload.data.deleteRoom.id
  );
  const newData = { ...data, rooms: newRooms };
  cache.writeQuery({ query: ALL_ROOMS_QUERY, data: newData });
};

You can now pass an option to the InMemoryCache constructor which will freeze the cache data to help prevent problems like this from happening: new InMemoryCache({ freezeResults: true }). In apollo-client v3, this freezeResults option will be enabled by default.

I use client.resetStore(); to resolve this issue

client.writeQuery({
  query,
  variables,
  data
});

client.resetStore();

I don’t know if it’s the best solution but it’s works for me

If anyone else is at the bottom of this thread and still confused… you really do need a deep clone of the new data object as per @rchasman 's investigation. But you also need to make sure you provide variables as per @JaosnHsieh . Neither of things were required in a previous version of react-apollo.

I’ve found a solution to this. It took a lot of digging around to find out how to get the parent to re-render. You can get the component to re-render by calling update in the Mutation props and/or refetchQueries to refetch the query and update local state.

update and refetchQueries will only update that specific component after the mutation. It will not re-render the parent or grand-parent components. If you want to reload the query (for a parent) in response to a user action, the Query component passes a method called refetch that you can call or pass down to child components when you want that component to refetch it’s query.

Here is an example.

<Query
              query={GET_RECORDED_ON_DATES}
              variables={{ patientId: this.props.patientId, limit: 1 }}>
              {({ loading, error, data, refetch }) => {
                let recordedOnDates = this.getDatesAndSort(data);
                let startDate = recordedOnDates[0] || START_DATE;
                return (
                  <div>
                    <div className="MainContainer__section MainContainer__section--header">
                      <TimelineHeader
                        categories={filteredCategories}
                        startDate={startDate}
                        endDate={END_DATE}
                      />
                    </div>

                    <div>
                      {filteredCategories.map(item => {
                        return (
                          <Fragment key={`category:${item.id}`}>
                            {item.isToggled &&
                              this.getCategoryComponent(
                                item.name,
                                item.id,
                                startDate,
                                componentWidth,
                                refetch
                              )}
                          </Fragment>
                        );
                      })}
                    </div>
                  </div>
                );
              }}
            </Query>

You can read more on refetching here: https://www.apollographql.com/docs/react/essentials/queries.html#refetching

Hi guys! I still have the issue, I tried to use client instead of cache but still the same - the cache gets updated, but it does not update our components. We are using the following code:

  const handleCreateSolution = async (solutionTitle, solutionDescription) => {
    try {
      const { data } = await createSolution({
        variables: {
          solution: {
              title: solutionTitle,
              description: solutionDescription
            }
        },
        update(cache, { data: { createSolution } }) {
          const { solutions } = cache.readQuery({ query: GET_SOLUTIONS });
          client.writeQuery({
            query: GET_SOLUTIONS,
            data: {
              solutions: solutions.concat([createSolution]) },
          });
        }},
      );
      handleCancel();
    } catch (e) {
      setError(e)
    }
  }

Is any solution already out there for it? Becuae otherwise we have to always refresh the page to get correct data for us.

I tried all the immutability solutions here. I see that the cache is updated with the new data. But the UI is not yet updated at all.

Hey @rohindaswani - when you’re calling writeQuery, are you attempting to update local state (as in https://www.apollographql.com/docs/react/essentials/local-state.html).

I found that all my queries that read from local state (rather than the remote server) do not get refreshed after calling writeQuery or writeFragment.

My workaround was to explicitly call a local mutation that modifies the local state instead of writing to the cache/proxy directly with writeQuery or writeFragment. Since the state/data is written locally, calling the mutation directly doesn’t penalize performance or anything (imo anyway).

Something like:

export const remoteMutationHOC = Wrapped => {
  return props => (
    <ApolloConsumer>
      {client => (
        <Mutation
          mutation={remoteMutation}
          update={(cache, { data: { result } }) =>
            //-- This is where I would normally call cache.writeFragment, but since the
            //-- data I need to update lives locally, I can call a local mutation. After the call
            //-- to the local mutation - all my queries that depend on the local data will get refreshed.
            client.mutate({
              mutation: localMutation,
              variables: { result }
            })
          }
        >
          {(mutation, { loading, data }) => (
            <Wrapped {...props} mutation={mutation}  />
          )}
        </Mutation>
      )}
    </ApolloConsumer>
  );
};

this was a pain in the ass.

BUT

client.cache.writeQuery({}) won’t work !!!

you have to use client.writeQuery({})

@rchasman I observed the same thing…

all our update functions were operating on data directly and then passing it to writeQuery (I think this came from examples in their old docs) and when I upgraded to the latest version, they all stopped working so there must be something under the hood in relation to immutability 😭

Did anyone come to a resolution with respect to this? I’m facing a similar problem in that when I add the updated data to the cache with writeQuery the component doesn’t re-render. I’m also facing a related problem in which I need the component’s parent to re-render as well since the underlying data has changed. Any thoughts on how to do that?

Ok I’ve managed to make it work by modifying my update function Previous version:

const update = (cache, payload) => {
  const data = cache.readQuery({ query: ALL_ROOMS_QUERY });
  data.rooms = data.rooms.filter(
    room => room.id !== payload.data.deleteRoom.id
  );
  cache.writeQuery({ query: ALL_ROOMS_QUERY, data });
};

After refactor:

const update = (cache, payload) => {
 // make a copy of the cachedResponse and not reference it directly
  const data = { ...cache.readQuery({ query: ALL_ROOMS_QUERY }) };
  data.rooms = data.rooms.filter(
    room => room.id !== payload.data.deleteRoom.id
  );
  cache.writeQuery({ query: ALL_ROOMS_QUERY, data });
};

That’s what worked for me. Still there must have been some change in apollo-client between 2.4.* and 2.6,* that prevents the former code to work

Please see https://github.com/apollographql/apollo-client/issues/4398. Long story short, this isn’t a bug - it’s by design. Hopefully PR https://github.com/apollographql/apollo-client/pull/4664 helps address this in the docs, but if anything still isn’t clear, please let us know (or better yet, fire over a new PR). Thanks!

Thanks for the tips here everyone. Had the same issue but solved it using @rchasman’s method. It didnt work at first but realised I had forgotten to use the variables for the query when using writeQuery()

I’ve tried all of these and NONE of them work for me. So the next question is: how can you verify if the update issue is due to writeQuery not triggering an update, or is useQuery is not updating?

Or stated in other terms: is there any way of debugging if your cache is actually updating properly from a writeQuery without having a query firing?

u can use cache.writeQuery. I think The problem is due Object.is comparasion in pure components or hooks. I solved the problem using “immutable” logic in data. lodash.cloneDeep works very good for this.

update: (cache, { data: { createTodo } }) => {
      const data = _.cloneDeep(cache.readQuery({ query }));
      data.todos.push(createTodo);
      cache.writeQuery({ query, data });
    },

@Keksinautin deep cloning the whole tree seems like a bad idea since it will rerender the entire tree. it’s better to just change what actually changed. It’s the same pattern used in redux

@obedm503 thank you, that is an interesting point. I may be wrong, please correct me if so, but as I know React does not compare states especially by link during the change detection, it compares the virtual dom and by value. This means that only really changed parts of the dom-tree will be rerendered. https://blog.angularindepth.com/what-every-front-end-developer-should-know-about-change-detection-in-angular-and-react-508f83f58c6a

@dylanwulf Thank you, actually I was just reading about freezeResults the same time you posted this. Also about

new ApolloClient({ assumeImmutableResults: true })

here and here https://github.com/apollographql/apollo-client/pull/4543

As others have pointed here, you have to do a deep copy of the data in order for it to re-render. Keep in mind that Object.assign doesn’t do a deep copy of an object.

the solution for me was to spread the data in as @JaosnHsieh suggested: (https://github.com/apollographql/apollo-client/issues/3909#issuecomment-516457707)

client.writeQuery({ 
                    query: ListRecipes,
                     data: {
                         listRecipes: {
                             items: [
                                ...dataInCache.listRecipes.items, newRecipe
                             ],
                             __typename: "RecipeConnection"
                         }
                     } 
                });

@charles-leapyear - thanks for that hint. I was tearing my hair out with this last night, woke up this morning to see your comment. I too was working directly on the data object. Switched over to using const newData = {...data} and it works perfectly now. Hope this might help someone. Cheers!

I am also facing the problem its updated the cache but no updating the component

 let data = cache.readQuery({ query: wsGroups, variables: { w_id: wid } });
        console.log(data)
        data.wsGroups = data.wsGroups.map(group => {
            if (group.group_id === group_id) {
                group.members = group.members.filter(member => member.user_id !== payload.data.deleteMemberInWsGroup.user_id)
                return group;
            }
            else {
                return group;
            }
        });
         cache.writeQuery({ query: wsGroups, data: data, variables: { w_id: wid } });
           // here i can see that cache is updated
         console.log(cache.readQuery({ query: wsGroups, variables: { w_id: wid } }))

    //but component props is not changed

Tried everything above and nothing was working. Upgraded from 3.1.5 to 3.3.15 (latest as of time of writing) per @LucaProvencal 's suggestion above and the problem disappeared.

I overlooked this for far too long: make sure you are on the latest Apollo version. I switched from apollo-client ^2.6.3 to @apollo/client ^3.2.5 and made sure I am importing ApolloClient as follows:

import { ApolloClient } from '@apollo/client';

None of the above solutions were working for me until I did this. Cache updating appears to be working now.

I have the same problem, but the reason is that I called client.stop() by mistake.

On man, I think I am gonna give up on apollo state after working on it for over a week! I almost managed to fix this issue by using
returnPartialData: true Which works great if you are switching between views on the same stack in Expo, but the moment you unmount the view (like in a modal) the whole thing goes back to its initial state. Back to redux so I can spend my time working on my important stuff!

Hey folks, if you’re using @apollo/client (AC3), please give the latest beta version (3.0.0-beta.46) a try, as we’ve made some substantial improvements to the automatic broadcast of cache changes (#6221 recently, and #6050 before that, in beta.40).

I can’t begin to say this update will solve all the problems that have been raised in this thread, but there’s a reasonable chance that many of them will be fixed/improved, I think.

Thanks for everyone’s patience while we fix this behavior once and for all.

@raelmiu you can inspect the cache before and after a read or write through the devtools

@nadzic I was in the same boat, using client.writeQuery instead of cache.writeQuery, deep cloning and other stuff helped me none. Only the solution provided by @rchasman worked. I think you should give it a try.

I was just tearing my hair out over a regression where an existing component doesn’t consistently update anymore after a mutation call, update : writeQuery.

I tested render, and it appears not to receive new props after a writeQuery from the mutation update even though the cache seems to be right (but sometimes it does work).

I played around a bit and was relieved (and confused) to see it behaving properly and consistently after some very minor changes making the data write immutable. Here’s some examples:

Bad, flaky component re-rendering:

      update: (cache, { data: { createFieldMapping } }) => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        data.fieldMappings.push(createFieldMapping);
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data,
        });
      },

These very minor changes (can you spot them?) made the mutation update work flawlessly again:

      update: (cache, { data: { createFieldMapping } }) => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data: { fieldMappings: [...data.fieldMappings, createFieldMapping] },
        });
      },

Seems like it has something to do with immutability.

Here’s another example with writing for a delete mutation:

Not updating after mutating:

      update: cache => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        data.fieldMappings = data.fieldMappings.filter(o => o.id !== id);
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data,
        });
      },

Works again:

      update: cache => {
        const data = cache.readQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
        });
        cache.writeQuery({
          query: fieldMappingsGQL,
          variables: { type, integration },
          data: {
            fieldMappings: data.fieldMappings.filter(o => o.id !== id),
          },
        });
      },

So I’m pretty confused about why this works, but I’m hoping this account helps someone else or helps Apollo fix a bug.

Well, that solution didn’t work for me, I had to deep clone the readQuery object for it to re-render in the components it had to.

Intended outcome: Components update automatically after cache modification with writeData or writeQuery. You repeat it everywhere in your docs:

Any subscriber to the Apollo Client store will instantly see this update and render new UI accordingly.

Actual outcome: Components never get updated after writeData or writeQuery.

You have to call broadcastQueries() like so:

this.props.client.queryManager.broadcastQueries();

in order to force your <Query> tags to reload themselves to render your new cache data. But after you call broadcastQueries() a new issue arise - it reloads ALL your <Query> tags, not just those that you need. Huge performance issue.

ANd you have nothing in your docs about it. Question here

How to reproduce the issue:

class FooComponent extends PureComponent {
  
  componentDidMount() {
    
    const query = gql`
      query QQQ {
        Me {
          __typename
          id
          something
        }
      }
    `;
    
    // I call writeQuery manually
    // How does <Text> input change instantly with new value?  
    // Or change it to writeData
    this.props.client.cache.writeQuery({
      query: query,
      data: {
        Me: {
          __typename: 'User',
          id: 'be2ae9d718c9',
          something: 'ABSDEF'
        }
      }
    });
  }
  
  render() {
    
    let something = this.props.Something.something;
    
    // How does <Text> input change instantly with new value 
    // after I call writeQuery in componentDidMount above?
    return (
      <View>
        {/* HOW DOES IT CHANGE instantly after writeQuery or writeData ?? */}
<Query query={ GET_SOMETHING }>
      { params => {
        const data = get(params, 'data.Me.something', {}) || {};
        const something = data.something;
        return (
          <Text>
            {something}
          </Text>
        )
      } }
    </Query>
      </View>
    )
  }
}

export default compose(
  withApollo,
  graphql(getSomethingQuery, {
    name: 'Something'
  }),
)(FooComponent);

Versions

  System:
    OS: macOS High Sierra 10.13.4
  Binaries:
    Node: 8.11.3 - /usr/local/bin/node
    npm: 5.6.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 68.0.3440.106
    Safari: 11.1
  npmPackages:
    apollo-boost: ^0.1.4 => 0.1.10 
    apollo-cache-inmemory: ^1.1.0 => 1.2.5 
    apollo-client: ^2.0.3 => 2.3.5 
    apollo-link: ^1.0.3 => 1.2.2 
    apollo-link-http: ^1.2.0 => 1.5.4 
    react-apollo: ^2.1.1 => 2.1.9 

broadcastQueries Does not work for me