Errors on useSignOut

[cdedreuille]

I'm a bit confused by the syntax of the auth hooks. On signOut for example:

const [{ error, fetching }, signOut] = useSignOut()

async function onClickSignOut() {
  const { error } = await signOut()
}

if (error) return <div>Error signing out</div>
if (fetching) return <div>Signing out</div>

• You have 2 times error. ESLint is throwing an error as it doesn't know which is being used in the render.
• Why having fetching if nothing is actually being fetched?

Should something like make more sense:

const signOut = useSignOut()

async function onClickSignOut() {
  const { error } = await signOut()
}

if (error) return <div>Error signing out</div>
if (fetching) return <div>Signing out</div>

[tmm]

You have 2 times error. ESLint is throwing an error as it doesn't know which is being used in the render.

I'm surprised that eslint isn't able to identify the correct error. Couple options available.

Rename error when destructuring:

const [{ error: signOutError, fetching }, signOut] = useSignOut()

async function onClickSignOut() {
  const { error: someOtherError } = await signOut()
}

if (signOutError) return <div>Error signing out</div>

Don't destructure error:

const [signOutResult, signOut] = useSignOut()

async function onClickSignOut() {
  const result = await signOut()
}

if (signOutResult.error) return <div>Error signing out</div>

Why having fetching if nothing is actually being fetched?

fetching is a pattern used throughout react-supabase and inspired by urql's API. fetching is true when some network request is active. In this case, fetching is true when the execute function signOut is called.

[cdedreuille]

I'm surprised that eslint isn't able to identify the correct error.

It's usually good practice to not name variables the same way. In your example, what's the difference between signOutError and someOtherError? I actually ended up using useClient and const { error } = await supabase.auth.signOut() as it's simpler to use than the hook.

I understand that you're trying to follow urql's structure but I'm just challenging the actual need for it if the result ends up being more difficult to use than the normal version.