[Question] Objects within list change after mutation of the list

Hi there,

I did not find a related discussion, so I’ve opened a new issue. Not sure though if it is an issue or intended behaviour (just not mine). Thanks in advance for shutting some light on this and any kind of explanation!

I’ve been trying Apollo on a simple list to test paging and simple mutations. For simplicity assume the following easy query-result structure…

[
 { id: "item-1", value: "a" },
 { id: "item-2", value: "b" },
 { id: "item-3", value: "c" },
...
]

This result is passed to a List component and each entry is then passed to ListItem components. So far so good.

I then delete “item-2” via a mutation.

const id = 'item-2';
mutate({
        variables: { id },
        resultBehaviors: [
          {
            type: 'DELETE',
            dataId: id,
          },
        ],
      }),

That’s pretty neat, as the item is automatically removed from the list and of course the list re-renders due to the changed list. But all my remaining list items are re-rendered as well!

Although all other objects within the list have not been touched by the mutation, they get re-created somehow (new reference, same values) and a simple === check in shouldComponentUpdate of my list item does not help anymore…

The same goes for paging. When incorporating fetchMore results into the list, all the previous items of the list seem to be re-created as well. And thus re-render. I am implementing paging to reduce the required network-traffic of course, but also to reduce the amount of items I need to render in one go (10, then 10 more, etc), but now it renders 10, then 20, 30, … which is not what I want to achieve.

When implementing such things in previous projects, I used immutable.js for my stores, especially due to performance concerns. I went with the assumption that the Apollo Client would do these things under the hood (out of the box). Or at least the remaining items should be left untouched.

I am pretty confused about this behaviour. Maybe I am missing a simple point and did a mistake. Any explanation on that matter would be highly appreciated!

Thanks and kind regards, Daniel

[kachkaev]

We’re also facing this issue (see #945) and it causes pretty large chunks of virtual DOM to be re-rendered. Let’s say you have three lists with 1000 items in each and you only mutate one attribute in one item. Even if you carefully implement updateQueries and patch only one little node out of the whole data tree, all related components fail to shallow compare their props.

We’d be really glad to see this fixed in Apollo client!

[calebmer]

Referential equality for data returned by the Apollo Client was implemented in https://github.com/apollostack/apollo-client/pull/1136 and released in 0.7.x so now to see if data has changed you can simply use === 👍

Let me know if this isn’t enough.