Allow the user to pass in a pre-existing Auth0Client

[a-type]

Describe the problem you'd like to have solved

I'd like to be able to easily integrate Auth0 into a client defined statically in my app (such as ApolloClient) without sacrificing the convenience and features of auth0-react.

Describe the ideal solution

The Auth0Provider component would accept a single client prop, as an alternative to the current props which act as configuration options to be passed to an internally created client instance. This client would be an Auth0Client instance created with auth0-spa-js.

I could then create my own Auth0Client, plug it into my ApolloClient instance using a link, and then provide it to the rest of my app, and I still get the nice convenience of cached authentication state and user data from auth0-react.

Alternatives and current work-arounds

1. Re-implement features of auth0-react in my own custom React context, like the caching behavior for important information.
2. Expose or otherwise "steal" the client which auth0-react creates using some terrible magic.

Additional context

For an analogous example of how this is done, see Okta's React library.

This is, in my opinion, the most robust and seamless way to provide higher levels of user customization to a library like this one without complicating the usage for beginners or exposing some kind of static access pattern through a ref or similar confusing method.

Ideally you could just take the client prop and toss it straight into your useState which already exists in the Auth0Provider if it's provided instead of creating your own.

[adamjmcgrath]

Hi @a-type - thanks for your suggestion.

We've decided not to support this feature because adding a client option would unnecessarily expose the internals of the SDK and would introduce a bunch of complexity around initialising the SDK differently depending on the state of the client.

Have a look at this #97 (comment) for a solution to using the SDK with an Apollo Client.

[a-type]

I've seen similar approaches before. I'm a bit concerned about the re-rendering implications of instantiating a new Apollo Client within the render function of a React component. This only seems to work if you are completely confident your top-level component will never be re-rendered; otherwise your GraphQL cache would disappear. At least that's how I understand it currently.

In simple cases that might be reliable, but I don't tend to hang my hat on React doing what I think it should do - they're free to change or optimize how they re-render components at any time internally, and what's going on behind the scenes can often be more complicated than it seems, like Concurrent Mode.

If that's the verdict though, I suppose I'll implement my own version of Auth0 React bindings designed around this use case.

[lexwebb]

Ideally i dont want to jump on an old closed issue, but this is causing big issues in app development locally for me. Essentially using useAuth0 along with depending on its isLoading and isAuthenticated props breaks HMR. It is causes a full app re-render whenever I make changes to a react component as my page rendering is waiting for conformation on being authenticated. Allowing what @a-type suggested would allow me and others to fix this issue.

It seems like a common pattern, for example when using redux or simillar libraries it is usual to create and hold a reference to the store outside app render, and pass it in at render time, thus allowing HMR to do its thing and use existing page state. I'm not sure what you mean by 'exposing the internals of the SDK'. All information already in JS is available for anyone to see, along with all SDK internals.

This is of course unless there is another already accepted way of doing this, and i have simply not found the docs.