React Query Data Transformations
Tags: react, javascript, typescript, webdev
Published: 2021-03-10 22:31:01

Welcome to Part 2 of "Things I have to say about react-query". As I've become more and more involved with the library and the community around it, I've observed some more patterns people frequently ask about. Initially, I wanted to write them all down in one big article, but then decided to break them down into more manageable pieces. The first one is about a quite common and important task: Data Transformation.

# Data Transformation

Let's face it - most of us are _not_ using GraphQL. If you do, then you can be very happy because you have the luxury of requesting your data in the format that you desire.

If you are working with REST though, you are constrained by what the backend returns. So how and where do you best transform data when working with react-query? The only answer worth a damn in software development applies here as well:

> It depends.

— Every developer, always

Here are 3+1 approaches on where you _can_ transform data with their respective pros and cons:

## 0. On the backend

This is my favourite approach, if you can afford it. If the backend returns data in exactly the structure we want, there is nothing we need to do. While this might sound unrealistic in many cases, e.g. when working with public REST APIs, it is also quite possible to achieve in enterprise applications. If you are in control of the backend and have an endpoint that returns data for your exact use-case, prefer to deliver the data the way you expect it.

🟢 &nbsp; no work on the frontend
🔴 &nbsp; not always possible

## 1. In the queryFn

The _queryFn_ is the function that you pass to _useQuery_. It expects you to return a Promise, and the resulting data winds up in the query cache. But it doesn't mean that you have to absolutely return data in the structure that the backend delivers here. You can transform it before doing so:

```ts
const fetchTodos = async (): Promise<Todos> => {
    const response = await axios.get('todos')
    const data: Todos = response.data

    return data.map((todo) => todo.name.toUpperCase())
}

export const useTodosQuery = () => useQuery(['todos'], fetchTodos)
```

On the frontend, you can then work with this data "as if it came like this from the backend". No where in your code will you actually work with todo names that are _not_ upper-cased. You will also _not_ have access to the original structure. If you look at the react-query-devtools, you will see the transformed structure. If you look at the network trace, you'll see the original structure. This might be confusing, so keep that in mind.

Also, there is no optimization that react-query can do for you here. Every time a fetch is executed, your transformation will run. If it's expensive, consider one of the other alternatives. Some companies also have a shared api layer that abstracts data fetching, so you might not have access to this layer to do your transformations.

🟢 &nbsp; very "close to the backend" in terms of co-location
🟡 &nbsp; the transformed structure winds up in the cache, so you don't have access to the original structure
🔴 &nbsp; runs on every fetch
🔴 &nbsp; not feasible if you have a shared api layer that you cannot freely modify

## 2. In the render function

As advised in [Part 1](https://tkdodo.eu/blog/practical-react-query), if you create custom hooks, you can easily do transformations there:

```ts
const fetchTodos = async (): Promise<Todos> => {
    const response = await axios.get('todos')
    return response.data
}

export const useTodosQuery = () => {
    const queryInfo = useQuery(['todos'], fetchTodos)

    return {
        ...queryInfo,
        data: queryInfo.data?.map((todo) => todo.name.toUpperCase()),
    }
}
```

As it stands, this will not only run every time your fetch function runs, but actually on every render (even those that do not involve data fetching). This is likely not a problem at all, but if it is, you can optimize with _useMemo_. Be careful to define your dependencies _as narrow as possible_. `data` inside the queryInfo will be referentially stable unless something really changed (in which case you want to recompute your transformation), but the `queryInfo` itself will _not_. If you add _queryInfo_ as your dependency, the transformation will again run on every render:

```ts
export const useTodosQuery = () => {
    const queryInfo = useQuery(['todos'], fetchTodos)

    return {
        ...queryInfo,
        // 🚨 don't do this - the useMemo does nothig at all here!
        data: React.useMemo(() => queryInfo.data?.map((todo) => todo.name.toUpperCase()), [
            queryInfo,
        ]),

        // ✅ correctly memoizes by queryInfo.data
        data: React.useMemo(() => queryInfo.data?.map((todo) => todo.name.toUpperCase()), [
            queryInfo.data,
        ]),
    }
}
```

Especially if you have additional logic in your custom hook to combine with your data transformation, this is a good option. Be aware that data can be potentially undefined, so use optional chaining when working with it.

🟢 &nbsp; optimizable via useMemo
🟡 &nbsp; exact structure cannot be inspected in the devtools
🔴 &nbsp; a bit more convoluted syntax
🔴 &nbsp; data can be potentially undefined

## 3. using the select option

v3 introduced built-in selectors, which can also be used to transform data:

```ts
export const useTodosQuery = () =>
    useQuery(['todos'], fetchTodos, {
        select: (data) => data.map((todo) => todo.name.toUpperCase()),
    })
```

selectors will only be called if _data_ exists, so you don't have to care about _undefined_ here. Selectors like the one above will also run on every render, because the functional identity changes (it's an inline function). If your transformation is expensive, you can memoize it either with useCallback, or by extracting it to a stable function reference:

```ts
const transformTodoNames = (data: Todos) => data.map((todo) => todo.name.toUpperCase())

export const useTodosQuery = () =>
    useQuery(['todos'], fetchTodos, {
        // ✅ uses a stable function reference
        select: transformTodoNames,
    })

export const useTodosQuery = () =>
    useQuery(['todos'], fetchTodos, {
        // ✅ memoizes with useCallback
        select: React.useCallback(
            (data: Todos) => data.map((todo) => todo.name.toUpperCase()),
            []
        ),
    })
```

Further, the select option can also be used to subscribe to only parts of the data. This is what makes this approach truly unique. Consider the following example:

```js
export const useTodosQuery = (select) => useQuery(['todos'], fetchTodos, { select })

export const useTodosCount = () => useTodosQuery((data) => data.length)
export const useTodo = (id) => useTodosQuery((data) => data.find((todo) => todo.id === id))
```

Here, we've created a [useSelector](https://react-redux.js.org/api/hooks#useselector) like API by passing a custom selector to our _useTodosQuery_. The custom hooks still works like before, as _select_ will be _undefined_ if you don't pass it, so the whole state will be returned.

But if you pass a selector, you are now only subscribed to the result of the selector function. This is quite powerful, because it means that even if we update the name of a todo, our component that only subscribes to the count via _useTodosCount_ will _not_ rerender. The count hasn't changed, so react-query can chose to _not_ inform this observer about the update 🥳 (Please note that this is a bit simplified here and technically not entirely true - I will talk in more detail about render optimizations in Part 3).

🟢 &nbsp; best optimizations
🟢 &nbsp; allows for partial subscriptions
🟡 &nbsp; structure can be different for every observer
🟡 &nbsp; structual sharing is performed twice (I will also talk about this in more detail in Part 3)

---

That's all I have for today 👋. Feel free to reach out to me on [twitter](https://twitter.com/tkdodo)
if you have any questions, or just leave a comment below ⬇️