# Does \`subscribeToMore\` handle potential duplication?

**URL:** <https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109>\
**Category:** Client SDKs\
**Tags:** client\
**Created:** [January 17, 2025, 12:02am UTC](https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109 "2025-01-17T00:02:23Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jordanthornquest](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jordanthornquest/32/5484_2.png) [@jordanthornquest](https://community.apollographql.com/u/jordanthornquest)\
**Post date:** [January 17, 2025, 12:02am UTC](https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109/1 "2025-01-17T00:02:24Z")

</div>

I have two components, `NotificationsLabel` and `NotificationsIcon`. I have a query for each component, which fetches a list of notifications:

```graphql
query NotificationsLabelSearchRecommendations {
  searchRecommendations {
    _id
    recommendationType
  }
}

query NotificationsIconSearchRecommendations {
  searchRecommendations {
    _id
    recommendationType
  }
}

```

I also have a subscription for each component:

```graphql
subscription NotificationsLabelRecommendationChanged($tenantId: String!) {
  recommendationChanged(tenantId: $tenantId) {
    _id
    recommendationType
    subscriptionPubSubType
  }
}

subscription NotificationsIconRecommendationChanged($tenantId: String!) {
  recommendationChanged(tenantId: $tenantId) {
    _id
    recommendationType
    subscriptionPubSubType
  }
}

```

Each component calls their respective query with `useQuery` and calls `subscribeToMore` to listen for updates. In practice, this fetches an initial list of notifications and then updates the list when a notification comes in.

**However, when a subscription is retrieved by these components, I see a duplication occur.** Instead of having my list of notifications increment by +1, I see the same notification twice in each component.

* * *

My question is, do I need to check for duplicates in my `updateQuery` function? For example, I can do something like this:

```typescript
const updateQuery = (prevData, { subscriptionData }) => {
  const newRecommendation = subscriptionData?.data?.recommendationChanged;
  if (!newRecommendation?._id) return prevData;

  const prevRecommendations = prevData?.searchRecommendations ?? [];
  const hasNewRecommendation = prevRecommendations.some(
    ({ _id }) => _id === newRecommendation._id
  );
  if (hasNewRecommendation) return prevData;

  return Object.assign({}, prevData, {
    searchRecommendations: [...prevRecommendations, newRecommendation],
  });

}

```

But I’m not sure if this is required, or if there’s another way Apollo Client _should_ be handling this.

If it is required, how do I give consideration to performance if I am adding a subscription to large list?

---

<div class="post-metadata">

**Author:** ![jerelmiller](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jerelmiller/32/3314_2.png) [@jerelmiller](https://community.apollographql.com/u/jerelmiller)\
**Post date:** [January 17, 2025, 9:23pm UTC](https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109/2 "2025-01-17T21:23:40Z")

</div>

Hey @jordanthornquest 👋

I believe what you’re seeing is the result of each of those subscriptions writing to the cache, so you end up with duplicates. The value returned from `updateQuery` will write to the cache and broadcast those changes to active queries. Since both of your subscriptions are writing, they both broadcast to each query, and you end up with duplicates. I’d be willing to bet that you see those duplicates show up in the cache as well (you can use [Apollo Client Devtools](https://chromewebstore.google.com/detail/apollo-client-devtools/jdkknkkbebbapilgoeccciglkfbmbnfm) to inspect this, or `console.log(client.extract())` which logs the cache contents). On the request side, I’m willing to bet you’ll only see one operation make it through your link chain due to [`queryDeduplication`](https://www.apollographql.com/docs/react/api/core/ApolloClient#apolloclientoptions-querydeduplication), even through you’re calling `subscribeToMore` twice (in case you’re wondering why that might be happening).

That said, I’d recommend trying to lift that query up higher in your component tree if you can and share that to your two components. If that is not feasible, I’d recommend at the very least only having one of those components run `subscribeToMore`, but not both. Let the cache update from that subscription propagate to your other component that way.

Hope this helps!

---

<div class="post-metadata">

**Author:** ![jerelmiller](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jerelmiller/32/3314_2.png) [@jerelmiller](https://community.apollographql.com/u/jerelmiller)\
**Post date:** [January 17, 2025, 9:25pm UTC](https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109/3 "2025-01-17T21:25:02Z")

</div>

Oh and I should mention, I’m assuming that you’re using the same `$tenentId` in both subscriptions. If that is not the case, let me know!

---

<div class="post-metadata">

**Author:** ![jordanthornquest](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jordanthornquest/32/5484_2.png) [@jordanthornquest](https://community.apollographql.com/u/jordanthornquest)\
**Post date:** [January 18, 2025, 11:47pm UTC](https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109/4 "2025-01-18T23:47:22Z")

</div>

Hey Jerel,

This is immensely helpful and confirms what I was unsure of. You’re correct that the two queries use the same `tenantId`. Sounds like the best plan is to use a subscription in a higher-level component to update the query data with `updateQuery`, which would trigger re-renders for other components using the same query data. Is that correct?

---

<div class="post-metadata">

**Author:** ![jordanthornquest](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jordanthornquest/32/5484_2.png) [@jordanthornquest](https://community.apollographql.com/u/jordanthornquest)\
**Post date:** [January 19, 2025, 12:03am UTC](https://community.apollographql.com/t/does-subscribetomore-handle-potential-duplication/8109/5 "2025-01-19T00:03:47Z")

</div>

In the same spirit of working with the cache and avoiding duplication, is there a best practice for working with subscriptions and optimistic updates? I’ve done some research and found the following discussions:

- [Optimistic update for subscriptions · Issue #5267 · apollographql/apollo-client · GitHub](https://github.com/apollographql/apollo-client/issues/5267)
- [subscriptions - optimistic updates · urql-graphql/urql · Discussion #1423 · GitHub](https://github.com/urql-graphql/urql/discussions/1423)

It seems like there isn’t an elegant way to do the following flow:

1. A user action triggers a mutation (i.e. they add an item to a list)
2. The item is optimistically added to the cache, which triggers an immediate UI update
3. The server responds with a subscription event, which is used to update the cache and triggers another UI update

One StackOverflow discussion recommended checking for duplicate entries in the `prevData` object in both mutation and subscription functions, but that can get slow with large datasets. Would a better approach be to have mutations use the existing optimistic update flow and have the server filter/ignore sending subscription events that are triggered by the current user?

Thanks for your time ✌