RTK Query: selectFromResult must return an object (docs could be more clear on this)

[gillycheesesteak]

Edited based on discussion below

The docs could be more clear about the expected/required return value from selectFromResult (and maybe reasons for those expectations)

Original issue:

As the title states, if the selectFromResult function returns a value directly, it results in the following error:

rtk-query-react.esm.js:318 Uncaught TypeError: Cannot read properties of undefined (reading 'data')

The issue appears to stem from useQuery relying on useQueryState which returns undefined after a few renders, causing the above error on this line:

redux-toolkit/packages/toolkit/src/query/react/buildHooks.ts

Lines 963 to 972 in e454251

	const queryStateResults = useQueryState(arg, {
	selectFromResult:
	arg === skipToken || options?.skip
	? undefined
	: noPendingQueryStateSelector,
	...options,
	})
	const { data, status, isLoading, isSuccess, isError, error } =
	queryStateResults

This behavior may be intentional - if so, the docs should be updated to reflect that.

[phryneas]

The problem is not data (that would destructive fine if undefined), but the object it is on. Does your selectFromResult maybe return undefined in some conditions?

[gillycheesesteak]

If it does, shouldn't that just get passed along similar to when the return value is { data: undefined }?

[phryneas]

No, selectFromResult replaces the whole result object including isLoading and everything - it allows you to optimize renders, but also means that you are responsible about the whole return value now.

[gillycheesesteak]

In that case, I believe the documentation here is misleading:
https://redux-toolkit.js.org/rtk-query/usage/queries#selecting-data-from-a-query-result

[gillycheesesteak]

This line should call out that the return value should mimic a response (an object with the relevant data as a prop)

redux-toolkit/docs/rtk-query/usage/queries.mdx

Line 277 in e454251

Sometimes you may have a parent component that is subscribed to a query, and then in a child component you want to pick an item from that query. In most cases you don't want to perform an additional request for a `getItemById`-type query when you know that you already have the result.

And this paragraph should be more specific about what constitutes a "new object on every render" given that the code example returns a new object with a post property:

redux-toolkit/docs/rtk-query/usage/queries.mdx

Line 306 in e454251

Note that a shallow equality check is performed on the overall return value of `selectFromResult` to determine whether to force a rerender. i.e. it will trigger a rerender if any of the returned object values change reference. If a new array/object is created and used as a return value within the callback, it will hinder the performance benefits due to being identified as a new item each time the callback is run. When intentionally providing an empty array/object, in order to avoid re-creating it each time the callback runs, you can declare an empty array/object outside of the component in order to maintain a stable reference.

[phryneas]

You somehow have the misconception that it should return { data }. That is not the case. The example returns a post property and exactly that is the return value of the hook: { post }. There is no data and it is not required.
You get the error because your selectFromResult returns undefined, you would not get that error message if you returned an existing object without data.

[gillycheesesteak]

No, I understand what you are saying - I still think the documentation is misleading about what format is expected (an object, at minimum) and this paragraph does not line up with the example given.

If a new array/object is created and used as a return value within the callback, it will hinder the performance benefits due to being identified as a new item each time the callback is run.

[gillycheesesteak]

Consider the way a normal selector in redux would be used

const value = useSelector((state) => state.some.value)

The impression I got from the docs as written is that this should work, since there is no mention of needing to return an object or something "response-like"

[phryneas]

It does not need to be "response like". You can return any object. { foo: "bar"} is perfectly fine.

There is no requirement to the shape of the return value apart from it being an object, however that might look. I honestly do not understand what you mean with"response like" at this point.

[phryneas]

I'm on mobile here, so I try my best to answer you and I might be missing something here, so please bear with me.

[phryneas]

Yeah rereading this we should probably add some runtime warning in dev mode as well as a warning in the docs - I had assumed that the docs were already pretty clear showing a return object and destructuring even though it's only one value.

[markerikson]

The biggest caveat with returning a primitive here is that we still try to attach methods to the object like refetch, so if it isn't an object that won't work at all.

[gillycheesesteak]

It does not need to be "response like". You can return any object. { foo: "bar"} is perfectly fine.

Understood. I understand what I was doing wrong now, but I think the docs could be more clear.

The fact that some lifecycle methods will be added to whatever you return is why I was calling it "response-like". It means that your actual selected value should be a property of the object you return, not returned directly from selectFromResult