Q. Should hooks return an Object or an Array?

makes sense: snapshot.data(); snapshot.id

doesn’t: value.data(); value.id

Just food for though. I see you pushed 1.0 so I doubt you wanna make breaking changes. I can just wrap anyway

[cmmartin]

+1 for returning an array so we can destructure with multiple hooks without doing this…

const { value: user, loading: userLoading, error: userError }  = useDocument(...)
const { value: widget, loading: widgetLoading, error: widgetError }  = useDocument(...)

I also agree on the order [value, loading, error]

Not convinced we should throw the error though. You always have the option to throw in userland if we don’t do it, but it’s hard to avoid it if we do. AFAIK you can’t call a hook inside a try block

[chrisbianca]

I’m still torn, so I’m going to leave this open for the time being.

I can understand your rationale, but equally, I wonder whether the “non standard” hook libs return objects because that’s what users and developers are used to. Array destructuring is a relatively new concept and certainly hooks are one of the first mainstream implementations that I’ve seen. It could be that over time, it becomes more common to return arrays for this sort of thing.

I’m also curious to understand what you meant by losing dot access of properties or the ability to ...rest properties?

With array destructuring, you could still do the following:

const [user, ...rest] = useAuthState(firebase.auth());
const [{ displayName, email, ...rest }, initialising] = useAuthState(firebase.auth());