Updating state based on subscription results

[Kingdutch]

I'm using GraphQL subscriptions for a notification system. The notifications are fleeting, so they're pushed down the subscription pipeline once and have no other back-end storage.

The problem that I'm running into is that I'd like to show the notifications in the React UI before a user dismisses them. However, I'm not sure where to store them.

What is the best way to move messages from a subscription into some sort of client-side state that I can manipulate without breaking React?

Things I've tried

I've tried creating a subscription handler which calls a setState to keep track of them. However, this causes issues because React may be in the middle of a re-render when that happens causing errors. (Cannot update a component while rendering a different component. To locate the bad setState() call inside component, follow the stack trace as described in https://fb.me/setstate-in-render). In my specific case it's caused by another subscription message that does update the cache, making it easily reproducible, but this could also coincide with a user action that triggers a re-render.

An alternative thought I had was to see if I can write them to the Graphcache cache, but I don't think that's a good idea, because I wouldn't be able to remove them. Since they're not stored on the server but just sent as messages, there would be no mutation to remove them from the cache.

The component already re-renders when the subscription data is updated so I thought of just using the return value of the useSubscription hook instead of passing a handler. However, all the ways I can come up with still require a setState call during render, to ensure I can show multiple notifications at once and let the user decide when the remove them.

[kitten]

Why don't you just keep the current notification in the hook's state and use an effect to update a separate store?

This way you can build up an index of notifications completely separately from the subscription's state

[Kingdutch]

Posting out my thoughts here helped :D After writing the post I thought of the same concept. Ending up with the following ReScript code.

  let (response, _) = ReasonUrql.UseSubscription.useSubscription(
    ~subscription=module(InAppNotificationSubscription),
    ~handler=NoHandler,
    ~pause=!hasFocus,
    ()
  );

  React.useEffect1(() => {
    let notification = response.data
      ->Belt.Option.map(data => data.viewerInAppNotification);

    switch (notification) {
      | Some(notification) => switch (notification) {
        | #NewChatMessageInAppNotification(data) => notify(Reapop.Notification.make(
            ~title=data.message.sender->Belt.Option.mapWithDefault("", s => s.senderDetails.displayName),
            ~message=createChatMessagePreview(data.message.content),
            ()
          ))
        // We can't handle future added values yet.
        | #FutureAddedValue(_) => ()
      }
      | None => ()
    }

    None
  }, [response.data])

It feels weird to use an effect for this because it's essentially delaying the update and possibly causing more renders than needed (one render for the subscription, one for the state update).

Having someone else come to the same conclusion makes it feel a little less weird though :)