Improve accuracy of AuthState type definitions

[supermacro]

Describe the problem you'd like to have solved

Main Problem: Usage of any on User type and hard-to-find information on what User really represents

I personally learn more about a library and the set of its possible behaviours by reading the types. Unfortunately, when I stumble upon an any, not only do I not gain insight into the meaning of a type, I also now have to deal with extreme ambiguity in my own code.

Specifically, I am referring to the AuthState interface which defines a field of user of type any.

Neither the code itself, nor the React SDK docs actually tell me what user really represents.

I am inclined to believe that it actually represents an ID token given that when I console.log user I get an object with a sub field.

Secondary Problem: Potentially Non-Sensical Types

As it stands, the AuthState definition implies that you can have a state that is:

  {
    isAuthenticated: true,
    isLoading: true,
  }

What does isLoading === true && isAuthenticated === true mean? Is this a valid state? My intuition tells me it isn't, but maybe i'm wrong!

I don't really want to cover this problem here, but I just wanted to bring this to light. A better solution is to define AuthState as an algebraic data type. Example:

type AuthState
  = { state: 'loading' }
  | { state: 'authenticated', user: User }
  | { state: 'failed', error: Error } 

Describe the ideal solution

Replace export type User = any; defined in

auth0-react/src/auth-state.tsx

Line 1 in 2ca701e

export type User = any; // eslint-disable-line @typescript-eslint/no-explicit-any

with a more accurate type definition. Or, at the very least, use unknown as at least this is typesafe.

Alternatives and current work-arounds

One solution is to override / supersede the type definition of User in my own code.

declare module '@auth0/auth0-react' {
  // currently I think `User` is a IdToken but I need confirmation
  export type User = IdToken
}

Additional context

None, other than I really like it when libraries use unknown instead of any. But regardless, thank you for your awesome open source library! 🙂

[adamjmcgrath]

Thanks for raising this @supermacro

We can't change user to unknown as this would be a breaking change. But we can probably make an improvement on any. We'll take a look at this the next time we're making updates to this SDK.