
I've found [react-query](https://react-query.tanstack.com/) to be pleasantly straightforward and easy to use in managing server-side state on React and React Native apps, with plenty of support and resources from the likes of [TkDodo's blog](https://tkdodo.eu/blog/practical-react-query) and [online courses](https://ui.dev/react-query?coupon_code=aQcnd).

React Query deals with, you guessed it, [queries](https://react-query.tanstack.com/guides/queries). As you build up your React application, you will find yourself facing some of these scenarios:

- you have queries that execute depending on the data returned from an earlier query: you can run conditional queries like in the guide on [Dependent Queries](https://react-query.tanstack.com/guides/dependent-queries).
- you have queries that can run in parallel: [`useQueries()`](https://react-query.tanstack.com/guides/parallel-queries) is there to solve parallel queries
- you have the same query that will be requested by multiple components in the same render cycle: It's more favourable to request for the same query multiple times than to perform [props drilling](https://blogs.perficient.com/2021/12/03/understanding-react-context-and-property-prop-drilling/), as you can configure [`staleTime`](https://react-query.tanstack.com/guides/important-defaults) to your needs

TkDodo has written about [creating custom hooks](https://tkdodo.eu/blog/practical-react-query#create-custom-hooks). Using custom hooks makes reading a component's code a breeze, because `useQuery` and how data is fetched gets colocated together in a custom hook. For example, a custom hook to fetch the list of todo items:

```typescript
export const useTodoListQuery = (filter: Filter = {}) => useQuery(['todos', filter], () => fetchTodoList(filter));
```

As I encountered more of those scenarios I described earlier, I found the need to reuse queries written in `useQuery` to also be used in `useQueries` for parallel execution. To make things more manageable, I decided to write utility function for constructing query options:

```typescript
export const buildTodoListQueryOptions = (filter: Filter) => ({
  queryKey: ['todos', filter],
  queryFn: () => fetchTodoList(filter),
});

export const useTodoListQuery = (filter: Filter = {}) => useQuery(buildTodoListQueryOptions(filter));
```

In the event that I need to build a portion of User Interface that needed to run the `useTodoListQuery` in parallel with something else, say loading calendar items, I can do this:

```typescript
export const buildTodoListQueryOptions = (filter: Filter) => ({
  // ...
});

export const useTodoListQuery = // ...

export const buildCalendarItemsQueryOptions = (dateRange: DateRange) => ({
  queryKey: ["calendar", dateRange],
  queryFn: () => fetchCalendarItems(dateRange),
});

export const useCalendarItemsQuery = // ...

export const useLandingInfoQuery = (
  dateRange: DateRange,
  filter: Filter = {}
) =>
  useQueries([
    buildCalendarItemsQueryOptions(dateRange),
    buildTodoListQueryOptions(filter),
  ]);
```

This makes it easier to build composable queries. That said, I don't think everyone should start going around and pick out their query options from whereever `useQuery` appeared. The abstraction should only occur when there is a good enough reason to do so, like when a particular query needs to be used in multiple instances of `useQuery` and `useQueries` to enhance user experience and loading time.

What do you think?



Last week, I integrated [Utterances](https://utteranc.es) to my blog over a couple of hours and shortly after integration, I found out about [Giscus](https://giscus.app/) and [laymonage](https://github.com/laymonage) came over to tell me that Giscus comes "with a ready-to-use [component library](https://github.com/giscus/giscus-component)".

Being "heavily inspired by utterances", Giscus is similar in many aspects (client-side integration, custom themes, reactions etc.) leveraged on [GitHub Discussions](https://docs.github.com/en/discussions) to host comments rather than GitHub Issues. Since I was familiar with how Utterances worked by then, I was able to quickly switch over to Giscus in an hour or so. Additionally, Giscus allows you to:

- add reactions to the page itself - these are stored on the discussion original post and can be disabled by option
- replies to comments, nesting - this is a feature I understand to be not supported by GitHub Issues
- sorting of comments by oldest/newest
- configuring if the comment box should be placed above all comments - I preferred not to scroll through the long list of comments before adding my comment, though this is purely the user's preference.

One thing I was facinated about, was that the comments widget did not reload fully when themes changed. I dug into the component library's source code and found that Giscus's component library leverages on [message passing to the iframe](https://github.com/giscus/giscus-component/blob/main/web/src/giscus.ts#L202) to update changes occurred in the component props. When using Utterances, any change in the props would result in a full reload of the script and iframe.

<img src="/assets/d3c0caadbf.gif" />

Giscus worked nicely, and I guess it's here to stay on my blog. Kudos to the Giscus team for building on the goodness that Utterances brought about.



Awhile back when I was reading up on [TkDodo's commentaries of react-query](https://tkdodo.eu/blog/practical-react-query), I noticed that TkDodo's blog has a nice comments section that looked very familiar. Upon closer inspection, I realised it was a widget called [Utterances](https://utteranc.es/), which allowed comments to be stored on a GitHub repository's issues.

This was neat for a fully static blog like mine, where I just don't want to host a database somewhere just to store comments. So I decided to try adding it to my built-time generated blog.

The setup was straightforward, I simply fill up the form in the `configuration` section, and it populates my input into the `<script>` tag below. I thought it would be a straightforward copy-paste, but TypeScript came complaining about `repo` being an invalid attribute for the `<script>` tag.

I looked around GitHub for React implementation or integration of Utterances, and found these two:

- <https://github.com/wicksome/utterances-react/blob/master/packages/component/src/Utterances.js>
- <https://github.com/b6pzeusbc54tvhw5jgpyw8pwz2x6gs/react-utterances/blob/master/packages/component/src/ReactUtterances.js>

So the trick was to dynamically assign the special attributes (like `repo`) to get by TypeScript complains for `<script>`. Along the way, I encountered the issue of the injected `<script>` tag being removed while the `<iframe>` tag as being injected asynchronously via `insertAdjacentHTML` (See [line 77](https://github.com/utterance/utterances/blob/36695bf89ffb2ea10eaa26f1b5cbc90477704b9f/src/client.ts) of the utterances source code).

My solution? To enable proper re-render of the Utterances widget, [I wrote a copy of the component](https://github.com/mauris/mauris.github.io/blob/main/apps/main/components/Utterances.tsx) taking references from the two other implementations mentioned above. My implementation takes care to track the number of script instances being loaded, and once the last instance has loaded, it will remove all duplicated instances, leaving only the last "up-to-date" instance in the DOM. This works neatly with changes in the site theme and current post.

I was quite pleased at how easy and straightforward Utterances can be integrated to provide comments and discussions into static sites. I hope to hear from people who's come by to read what I've written and give their thoughts too.

Thank you to the folks behind [utterances](https://github.com/utterance) for making the comments widget that made sense.


Sam's Blog

Giscus: Blog Comments with GitHub Discussions