Object is not a type that we'd like to use in this context, it behaves similarly to any that it just silent the errors without any actual gains.

Ideally, we should already have all the types of core entities available somewhere so that we can do this automatically. Given that it'd be a huge amount of work, we could instead try to use generics here to let the users specify the correct types.

const { record } = useEntityRecord<PageRecord>( 'postType', 'page', id );
// record: PageRecord

It's a bit more complicated to get right though, I'm willing to help if you encounter any problems!

Also, if the data is still resolving, I think the type of this value will be null?

Object is not a type that we'd like to use in this context, it behaves similarly to any that it just silent the errors without any actual gains.

The gains are that we're able to use TypeScript :-) I went for the minimal typing on purpose for the reasons you have mentioned – there aren't many types defined in core-data. Thinking about it more, it shouldn't be a big problem for the JavaScript consumers of the code, and if it is then any may be moved to the consumer code. So yes, generics sound like a good approach 👍

Hey @kevin940726, you will like this PR: TypeScript definitions for core-data entity records

I guess we don't need this either, as this is essentially the same as !isResolving.

Not exactly, isResolving and hasResolved may both be true when the record is being re-requested. It is how the meta selectors in @wordpress/data work so I'd rather not change that logic here. I thought it's confusing and now your comment reassured me, so I'll add that to the docstring.

isResolving and hasResolved may both be true when the record is being re-requested.

Huh, interesting! Then what's the difference between hasResolved and !!data?

Just checked the implementation in:

isResolving and hasResolved may both be true

I think this is not possible? Or maybe I'm missing something elsewhere 🤔 . I guess something like isSuccess and isError might be more useful than hasResolved. It's also arguably more approachable given that the name directly inherits the status.

When I said it's confusing, I didn't realize I am the one who's confused :D I think you're right – hasResolved and isResolving can't both be true. I'm not sure how I concluded they can – thanks for staying alert!

Let's figure out what do to do next. We have three boolean flags: hasStarted, hasFinished, and isResolving. The following combinations are possible:

• false, false, false – the resolution hasn't started yet, the initial state
• true, false, true – the resolution is in progress
• true, true, false – the resolution has finished

so that's three values to represent. I think we need at least hasStarted and isResolving then, but hasFinished and isResolving works just as well.

what's the difference between hasResolved and !!data?

The resolved data can be any value at all, including null, undefined, false, and so on. We can have hasResolved === trueand!! data === false`.