
I am a massive fan of [React Query](https://tanstack.com/query/v4). It has grown on me to the point that it's now one of the first tools I set up when I start on a new project. If you're not familiar with React Query, at a high level it's a library that helps you manage your data fetching and client-side caching in React applications.

React Query makes it easy to write declarative data fetching code that gets access to all sorts of nice features like request states (`isLoading`, `isFetched`, etc), query deduping, query cancellation, cache control and persistence, and a [whole lot more](https://tanstack.com/query/v4/docs/comparison) &mdash; and it gives you the power to manipulate your client-side cache in pretty much any way you might need.

If you just need to fetch some data you can use [`useQuery`](https://tanstack.com/query/v4/docs/reference/useQuery) with one or two lines of code and be on your way, but as your application grows in complexity you may find yourself wanting to connect to a websocket to receive real-time updates from your server. Fortunately, React Query makes this quite painless.

## Querying data

When you're ready to start updating your client via websockets, if you're already using React Query, the good news is that nothing really changes with the way you fetch your data.

```js
const { data } = useQuery({
  queryKey: ['replies', postId],
  queryFn: () => fetchReplies(postId),
});
```

Here we've got a `fetchReplies` function that returns a promise that resolves to an array of replies for a given post. We're using the `queryKey` to identify this query, and we're using the `queryFn` to call our `fetchReplies` function.

## Subscribing to a websocket

In this example, we're going to use [Pusher](https://pusher.com). I like Pusher because they have an [open specification](https://pusher.com/docs/channels/library_auth_reference/server-library-reference-specification/) and there are other, self-hostable [alternatives](https://soketi.app/) that implement the Pusher spec. Meaning you can build on Pusher and if your application scales to the _incredibly expensive_ tiers of Pusher.com, you don't have to rewrite your entire socket architecture to cut some costs. You can just host your own server.

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (event) => {
    /* ... */
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

## Interacting with the cache

There are two ways that I typically approach passing a socket message along to React Query. Each are useful in different contexts, so we'll cover both and when you might want to use one over the other.

The first is to invalidate the query by `queryKey`, so that the next time that query is needed it'll fetch fresh data from the server. This approach minimizes the amount of data over the wire via the websocket and allows users to only fetch the data that they need, when they need it.

The second approach is to send the updated data through the websocket and then manually update the `queryClient` cache with that new data. This approach is better if you expect to have a frequent, small updates or if you expect a large number of concurrent consumers &mdash; and want to avoid triggering a thundering herd every time new data is available.

### Invalidate Query

When a socket event occurs, we'll use [`queryClient.invalidateQueries`](https://tanstack.com/query/v4/docs/reference/QueryClient#queryclientinvalidatequeries). The nice thing about React Query here is that if the query is actively being used, it'll refetch that data in the background and show the stale data in the UI until the new data is available. If that query is _not_ actively being used, React Query marks it as invalidated and fetches it the next time the user needs it. 

Using the same example from above, we'll fill out the `newReply` event handler.

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (postId) => {
    queryClient.invalidateQueries({
      queryKey: ['replies', postId]
    })
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

Now on the server, you can send a message to the `post-replies` channel with the `postId` as the event data:

```js
pusher.trigger('postEvents', 'newReply', postId);
```

### Manually update the cache

If you expect to have frequent, small updates &mdash; like a chat feature &mdash; or a large number of concurrent users it is probably better to ship the updated data over the websocket and update the cache by `queryKey` directly using [`queryClient.setQueryData`](https://tanstack.com/query/v4/docs/reference/QueryClient#queryclientsetquerydata).

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (reply) => {
    queryClient.setQueryData(
      ['replies', reply.postId],
      (cacheData) => [...cacheData, reply]
    );
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

In this case, we're still updating the same record by `queryKey` but instead of telling React Query to fetch the data next time it needs it, we just take the cached value as a parameter in our update function and append our new comment entry to the array.

And on the server side, rather than just sending the `postId` we'll send the entire `reply` object.

```js
pusher.trigger('postEvents', 'newReply', reply);
```



Using Websockets with React Query


I honestly can't tell if the Twitter acquisition is going off the rails or according to plan.

I'm not sure what will happen to Twitter over the coming weeks and months, but it seems inevitable that the outcome will at minimum be fragmentation of the various communities that I've followed and engaged with over the years.

If you're part of the contingent that's bailing on Twitter, I'm [@jonbellah@mastodon.social](https://mastodon.social/@jonbellah).

Bye bye, Birdie


After almost a decade working as an individual contributor — with a few short stints in engineering leadership-adjacent roles — I've decided to finally make the
jump to engineering management.

Today is my first day as an Engineering Manager at [Endeavor](https://www.endeavorco.com/story/).

Beyond learning an entirely new skillset, I'm particularly excited about this new role for a few key reasons.

First, Endeavor is just an incredibly interesting and exciting company to go to work for. They've got their hands in a broad swath of the sports and entertainment
industries, from being one of the largest [talent agencies](https://www.wmeagency.com/expertise/) and [sports and event management](https://img.com/expertise/)
companies in the world to being the parent company of the [UFC](https://ufc.com) and [PBR](https://pbr.com/) &mdash; and so, so much more.

Secondly, I'll be working with _several_ friends from my time at TED. The TED Tech team was one of the smartest and most close-knit groups that I've ever worked
with and getting a chance to go work with a bunch of them again is super exciting.

And lastly, I'll be leading a team at an internal incubator charged with innovating and building the next generation of Endeavor's business. The William
Morris Agency &mdash; the precursor to today's Endeavor &mdash; was formed almost 124 years ago&hellip; and a company doesn't survive for 124 years by remaining
stagnant. Endeavor has innovated and grown their business decade-after-decade and I'm looking forward to playing a (small) part in writing the next chapter of
that story.

I'll likely be hiring for my team very soon, so if you're interested in working with me, don't hesitate to [reach out](https://jonbellah.com/contact)!

Entrepreneur, software engineer, and amateur photographer.

Using Websockets with React Query

Bye bye, Birdie

Making the Jump to Engineering Management

Stay up to date

From YouTube