Clarification of the behaviour of refetchOnMountOrArgChange

[dwjohnston]

The refetchOnMountOrArgChange option is helpful for me, where when a component remounts I want the data the refetched regardless of what's already in the cache.

However, I was worried that if I had something like:

  const result = useGetPostQuery(
    { id: id }, //<-- This line here worries me
    {
      pollingInterval: globalPolling ? 3000 : 0,
      refetchOnMountOrArgChange: true
    }
  );

Then you would get a 'refetch every render' problem - because a new object is declared every time this component/hook renders.

However, this doesn't seem to be a problem.

I've a repro of this here, it's a modification of the Kitchen Sink example.

https://codesandbox.io/s/lucid-haze-qqntsp?file=/src/features/posts/PostDetail.tsx:1779-1963

1. Go to posts section, click between the 'A sample post' and 'A post about rtk-query' posts. Note that they refetch, which is the 'on mount refetch behaviour we want'
2. Click the rerender button. Note there is no refetch, which is also what we want.

I'm wondering how is this behaviour achieved? Is RTKQ stringifying the object to check for deep equality?

[dwjohnston]

It does look like that's the case. Here's the args serialisation function:

redux-toolkit/packages/toolkit/src/query/defaultSerializeQueryArgs.ts

Lines 9 to 37 in e454251

	export const defaultSerializeQueryArgs: SerializeQueryArgs<any> = ({
	endpointName,
	queryArgs,
	}) => {
	let serialized = ''
	const cached = cache?.get(queryArgs)
	if (typeof cached === 'string') {
	serialized = cached
	} else {
	const stringified = JSON.stringify(queryArgs, (key, value) =>
	isPlainObject(value)
	? Object.keys(value)
	.sort()
	.reduce<any>((acc, key) => {
	acc[key] = (value as any)[key]
	return acc
	}, {})
	: value
	)
	if (isPlainObject(queryArgs)) {
	cache?.set(queryArgs, stringified)
	}
	serialized = stringified
	}
	// Sort the object keys before stringifying, to prevent useQuery({ a: 1, b: 2 }) having a different cache key than useQuery({ b: 2, a: 1 })
	return `${endpointName}(${serialized})`
	}

Is this a potential problematic performance issue, if we had large args objects that happened to be going through as args, and they'd be doing that sort and stringify every render?

(But FWIF, at this point I'm not griping at all - one of my biggest bug bears with React is how the declaration of new objects will trip shallow equality checking and cause all sorts of issues for me, so that this doesn't, is quite a relief for me).

[phryneas]

If you rerender an unreasonable amount of times and have a very big object, it might be a problem, but usually it shouldn't be - and in that case you could still use useMemo for referential stability on your side.