Return a copy of data from useQuery

[webarnes]

This is slightly related to an older discussion (#530). useQuery currently returns the object from the cache by reference and any operations you perform on it affect other instances. In my case, for example, I have a list that is fetched from the server and used in a few places. In two places, it is sorted and since Array.sort() modifies the array, the sorting in one component modifies the order of the data in a completely different component.

Currently, I'm just careful about cloning any array returned by useQuery before modifying it, but I wonder if there is really any use case for returning the array by reference. It would probably avoid a lot of bugs if useQuery returned copies. I suppose I could have the queryFn return an Immutable but it strikes me as more reasonable for react-query to clone anything being returned from the cache.

In the alternative, it should at least be in the documentation so that it doesn't catch people by surprise.

[tannerlinsley]

Data returned by queries must be stable. If not, it would cause too many side effects and unnecessary memoizations throughout your application. As with most data models in react, immutability is implied unless stated otherwise. With that said, gel free to open a PR updating the docs with any information you feel would have helped you.

[webarnes]

Here's a contrived example:

const SortedList = ({sortKey}) => {
  const { data } = useQuery('fetchData', queryFn);
  if (sortKey) data.sort((a,b) => { a[sortKey] > b[sortKey] ? -1 : a[sortKey] < b[sortKey] ? 1 : 0});

  return (
    <ul>
      {data.map(entry => (
        <li key={entry.id}>{entry.value}</li>
      )}
    </ul>
  )
}

...

<SortedList sortKey="date" />
<SortedList sortKey="value" />
<SortedList />

Ok, I named the component poorly, but that last SortedList will end up sorted by date and value rather than in the original order. This could be solved by doing something like const sortedData = [...data].sort but I'm not sure that should be necessary.

[tannerlinsley]

It’s definitely necessary. And it would be in many other common state managers because Array.sort is mutative. Even React itself relies on immutability within props to perform render optimizations.

[tannerlinsley]

My suggestion here would be to const sorted = React.useMemo(() => [...arr].sort(), [arr])

[TkDodo]

That array sorting is a mutating operation is a very typical javascript gotcha, it catches the most seasoned devs off-guard. In TypeScript, you can use ReadonlyArray<T> as your return type from your queryFn, which will not allow you to use mutable operations on the Array (like sort or push). But in js, you need to remember it :)

[lpillonel]

Hi,
Related to this topic, I was wondering if there is any plan to return readonly (Object.freeze) or immutable object (e.g. Immer.js) data, at least in development mode in order to prevent unwanted mutations (like the sort or push as said before) ?

[TkDodo]

if we provide immer in development, but not in production, mutations will work in development, but not in production ;)

preventing unwanted mutations is imo the responsibility of the developers. There are many ways to achieve this:

• there are eslint rules that prevent mutations, like: https://github.com/jonaskello/eslint-plugin-functional/blob/master/docs/rules/immutable-data.md
• you can use TypeScript, which has readonly data that disallows mutation

[cesarramirez1912]

@webarnes managed to manipulate the data without changing the values ​​in another instance?

[webarnes]

I use useMemo like tannerlinsley suggested or just make a copy as I did in my original example. I made my peace with this behaviour when I realized that returning a new copy every time useQuery is called would probably break many other optimizations in React that rely on referential equality.

[cesarramirez1912]

@webarnes I'm doing it this way and the same exchange everywhere

Could you give me a solution?

   const { isLoading: isLoadingSales, data, error: errorSales } = useSales();

    const newData = useMemo(() => simplifyData(data), [simplifyData, data]);

    function simplifyData(sss) {
        var aux = [];
        const res = [...sss];
        res.map((sale) => {
            aux = [];
            sale.productos.map((producto) => {
                const find = aux.find(prod => prod.id === producto.id);
                if (!find) {
                    aux.push(producto);
                } else {
                    find.cantidad = find.cantidad + producto.cantidad;
                }
            });
            sale.productos = aux;
        })
        return res;
    }

[TkDodo]

I made my peace with this behaviour when I realized that returning a new copy every time useQuery is called would probably break many other optimizations in React that rely on referential equality.

it would not. react-query does a deep structural sharing internally, making sure only those parts of the returned structure that actually changed is different - the rest will be referentially stable. I've written a lot about these topics here:

• https://tkdodo.eu/blog/react-query-data-transformations
• https://tkdodo.eu/blog/react-query-render-optimizations

@cesarramirez1912 I can only encourage you to work immutably everywhere. No aux.push, no find. cantidad = and so on. While you do make a shallow copy of sss in the beginning, you still modify the product you find, which is still the same reference.

This has nothing to do with react-query, it's just about immutable programming. The same thing would happen if you modify state like this inside a redux selector.

[JongSikLim]

I suggestion to you, use with a react-hook-form. it would be big practice in this case.
When i change the field on input(react-hook-form), all reference points be changed.