When placeholderData is set, initial status is success

[eedv]

Describe the bug
When placeholderData is set, initial status is success

To Reproduce
Example: https://codesandbox.io/s/react-query-placeholder-data-h7hz4?file=/src/App.js

Expected behavior
From documentation is not clear if this is expected behavior. I understand the initial status success using initialData because is persisted in the cache, but if I have partial data to show I still need to know if the rest of it is loading

Smartphone (please complete the following information):
any platform

Additional context
I'm starting to migrate an app from redux-saga to react-query and is really wonderful
Thanks

[tannerlinsley]

This is by design. If you need to use placeholder data while the query is loading, simply default your data variable to whatever you want:

const query = useQuery(...)
const data = query.data ?? defaultData

[tannerlinsley]

Also, you can still know if the query is fetching by using the query.isFetching property.

[nerdess]

@eedv here is an example if you (or anyone else that comes acress this problem) is using useQuery with destructuring and needs a default value:

     const {
       isLoading: chartLoading,
       error: chartError,
       data: chart = []       //chart will be an empty array until the request returns a result
     } = useQuery('barchart', api.barchart);

[mwmcode]

so if network request fails, will we still get placeholder/initialData in data?

[TkDodo]

so if network request fails, will we still get placeholder/initialData in data?

here is an extensive read about placeholderData, initialData and the differences between them:

https://tkdodo.eu/blog/placeholder-and-initial-data-in-react-query

[mwmcode]

Thanks @TkDodo, I actually came across your blog but looked at Error Handling

My issue was/is that my initialData was coming from an async fn, so the initial request gets undefined for initialData and thus when it fails, it fails with undefined for data.
I tried enable: false while reading initlalData from async fn, didn't help.

i don't want to do {...result, data: result.data ?? initDataFromAsync } but it seems the only way :\

---

Update
in case someone else finds themselves in similar situation, what ended up working for me is:

1. setting queryKey: undefined & enabled: false while awaiting for initial data value
2. once the value has been fetched, set queryKey & enabled: true

[TkDodo]

setting the queryKey shouldn't be needed. here is an example of async initialData done with dependent queries:

• I need to store a value, asynchronously, offline. Can this be done? #1288 (comment)

[mwmcode]

Thanks @TkDodo
Just FYI, setting queryKey seems to be needed here (at least when the 2nd query has initialData). Even in dependent queries example the 1st query is causing a change in the queryKey of the subsequent one. (once the 1st is resolved, its result (userId) is used in the queryKey of the 2nd query)

[mareksuscak]

This is by design. If you need to use placeholder data while the query is loading, simply default your data variable to whatever you want:

const query = useQuery(...)
const data = query.data ?? defaultData

I might be in the minority, but this is super counterintuitive to me. It seems that there's a general confusion around how this works and the expectation that provided the placeholderData, the query should start with a loading state. To me, placeholder data should semantically work exactly as the example above. It's even more confusing in Typescript where providing the initialData removes the loading option from the status field but the placeholderData doesn't.

To me, it comes down to the different use cases which drive my intuition. I'd use initialData when I have data from the server available at page load time and I want the page hydrated with the data immediately upon loading the page. I would want to use placeholderData when I'm loading the data on the client but need to provide a placeholder data to avoid having to account for nulls in all places through the use of a null object pattern (e.g. use Guest user object while loading the data about the actual User). Given the current behavior, I don't even know why I'd ever want to use the placeholder data. I'd argue that if queries with placeholderData started with a loading state, the user can still decide whether they display the loading state based on the loading status or the fetching status, or no? All that to say that I don't see a good reason to keep the current behavior but I acknowledge I might not be aware of other use cases where this is useful. placeholderData currently feel a little redundant and I don't have a good understanding of when it's useful.

EDIT: Reworded the last paragraph to express my thoughts in a clearer way.

[TkDodo]

and the expectation that provided the placeholderData, the query should start with a loading state.

loading state is used to describe and discriminate the data property. When you are in loading state, you cannot, per definition, have data. It is defined as:

status: 'loading',
data: undefined,
error: null

success state merely means that we have data. That is why you are in success state when you provide placeholderData.

I'd argue that if queries with placeholderData started with a loading state, the user can still decide whether they display the loading state based on the loading status or the fetching status, or no?

You can still do that by checking for the isPlaceholderData flag returned from useQuery.

placeholderData currently feel a little redundant and I don't have a good understanding of when it's useful.

I've written about the differences (and similarities) to initialData here: https://tkdodo.eu/blog/placeholder-and-initial-data-in-react-query

[mareksuscak]

You can still do that by checking for the isPlaceholderData flag returned from useQuery.

I didn't know that. Thank you. I guess we could use this flag instead or in addition to the loading flag to display content placeholders. I wonder if this should be mentioned in the description of placeholderData flag.

[TkDodo]

Good idea, do you want to contribute that?

[phatify]

Good idea, do you want to contribute that?

of course