
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?



It's been many years since I last blogged anything, especially on programming, software engineering and tech.

Watching [Yang Shun](https://github.com/yangshun)'s GitHub activities, I couldn't help but notice that he's been dabbling with _Next.js_ - a name that I came across occasionally but never really looked into seriously. Since I had some time on hand this week, I took the opportunity to read up and understand what Next.js was trying to achieve.

# Solving Common React Pain Points

As I dug, it turned out, Next.js was already solving common problems that I often encounter when building React apps:

- Deciding how files, pages, components are structured in the project folder
- Deciding how routing is done (despite everyone's using `react-router`, there's variance in flavour and how routers are structured)
- Deciding how code is transpiled (e.g. configuring Webpack, TypeScript etc.)
- Figuring how to do Server-Side Rendering (SSR) right
- Figuring how to get asset optimization done right

Next.js, as a framework, has structured and simplified the development workflow to get web developers straight into building the app.

# Learning Next.js

For me, the [tutorial](https://nextjs.org/learn/foundations/from-react-to-nextjs) was easy to follow as I had some background in React. If you only have experience in vanilla JavaScript, the [tutorial comes with steps](https://nextjs.org/learn/foundations/from-javascript-to-react) to help you get up to speed.

Once I was through with the tutorial, I figured that I'll try out Next.js by creating a blog that's similar to the tutorial, yet incorporating some of the niceties I'm familiar with, like:

- [Yarn Monorepo](https://semaphoreci.com/blog/javascript-monorepos-yarn-workspaces) - breaking down apps into reusable and composable packages sparks joy. In my blog's monorepo, I have two types of workspaces: `apps` and `libs`
- [TypeScript](https://nextjs.org/learn/excel/typescript) - I find typings help with santiy checks and sometimes make code easier to read
- [Tailwind CSS](https://tailwindcss.com/docs/guides/nextjs) - I could have gone with [MUI](https://mui.com/), but at this point I find it simpler to just have utility CSS classes rather than importing a full blown component library. I also like how Tailwind CSS makes it easy to incorporate dark/light theming
- [Sass](https://nextjs.org/docs/basic-features/built-in-css-support#sass-support) - expressive CSS rules, which goes hand in hand with CSS Modules in Next.js

# Additional Resources

After spending about 3 days on it, I was able to piece together [the blog](https://github.com/mauris/mauris.github.io) you see here, with much thanks to the following resources:

- The full tutorial to create a Next.js app: <https://nextjs.org/learn/basics/create-nextjs-app>
- An example of how to setup a monorepo with Next.js: <https://github.com/belgattitude/nextjs-monorepo-example>
- [Julia](https://bionicjulia.com/) gave some guidelines on setup (picked up `react-markdown` and `react-syntax-highlighter` from here, without having to explicitly write code to parse Markdown using `remark`): <https://bionicjulia.com/blog/setting-up-nextjs-markdown-blog-with-typescript>
- Guide on using GitHub Pages to host the exported Next.js app as a static webapp: <https://wallis.dev/blog/deploying-a-next-js-app-to-github-pages>
- Using `next-transpile-modules` to ensure workspace dependency packages/libraries get transpiled properly: <https://www.npmjs.com/package/next-transpile-modules>
- Using GitHub Actions to magically update GitHub Pages `gh-pages` branch whenever there are changes made on the `main` branch: <https://gregrickaby.blog/article/nextjs-github-pages>

# Conclusion

I must say it was quite a joy to work with Next.js and it took away some cognitive load I mentioned earlier. With that, I might continue working on more features for this blog (e.g. pagination, search) in my free time. Hopefully this will encourage me to write and reflect more upon my software engineering career and journey.


Sam's Blog

Posts tagged react

React-Query: abstracting query options

Next.js + TypeScript in a Monorepo