Expose the auth0Client statically

[maraisr]

Describe the problem you'd like to have solved

Right now the Provider requires all the Auth0Options defined as props. Which is fine. But ideally Id like to just give it a client potentially.

My use case is when you want React to know about auth things, but also things outside of react. Ie we use Relay, and its fetch method lives outside react, so there is no ability for me to get that accessToken without also having access to the client.

Describe the ideal solution

Being able to provide it with a client, rather than the options.

[adamjmcgrath]

Hi @maraisr - thanks for sharing your use case

Do you have an example app showing the problem, so I can investigate this?

[maraisr]

For sure I can create a repro repo! Will get one out to you soon.

[adamjmcgrath]

Hey @maraisr - I'm going to close this issue as it's been idle for a while - feel free to re-open if you want to continue the conversation

[maraisr]

Deeply sorry for the delay...

Here is a repro: https://github.com/maraisr/auth0-repro

I cannot send in a client here: https://github.com/maraisr/auth0-repro/blob/master/src/App.js#L50
But id like to get access to the JWT here: https://github.com/maraisr/auth0-repro/blob/master/src/App.js#L15

Please do assume you cannot recreate a relay environment between auth sessions, as there might be public fields you can request. My implementation locally currently checks if there is auth, and conditionally adds the auth header. But think that is irrelevant here.

The crux of the situation is; my relay fetchQuery method has no concept ties with React runtime, so the useAuth cannot inject tell it about a JWT.

cc @adamjmcgrath

---

Please do bare in mind; that clone will run, provided Auth0Provider accept a client, and have it validly configured. etc...

[adamjmcgrath]

Hi @maraisr

Thanks for sharing your use case - you should still be able to use the auth context when creating your relay environment, I've put an example here: https://github.com/maraisr/auth0-repro/compare/master...adamjmcgrath:patch-1?diff=split&w=1

Please do assume you cannot recreate a relay environment between auth sessions

You could cache the environment in the module if you don't want to recreate it.

let environment;
function createRelayModernEnvironment(getTokenSilently) {
  if (environment) return environment;
  ...
  return environment = new Environment({ ... });
}

Although I would try and tie the lifecycle of your relay environment with your app component (unless it's being shared amongst many apps on the same page). For one thing, it will make testing much easier

[maraisr]

Hi Adam! Thank you so much for the quick response.

I'll be honest; I messed up a critical part! The environment isn't created beneath a useAuth. Its much higher up. So sorry... This is getting way to complicated for me to articulate without spending the time to build our architecture in the open also. The short story is, our environment lives in shared space, that all apps with/without auth consume. I then have a requiresAuth: boolean as part of app config (https://github.com/maraisr/configs-webpack-plugin), if this is true then there is a magically babel added import of our auth layer, where it exposes a .getToken('silent') method. Which internally, calls auth0's sdk method, .getTokenSilently.

I do this for a couple reasons:

• Allows my MFE's to all share an environment dependency that will not bundle auth0 if the app doesnt require auth. This isnt federation ready, so in the near future this'll turn into a factory so an auth layer can be something, or noop.
• Our auth0 client is then also shared between MFE's, because when I federate them in, each app will be mounted into a host. Sure I could expose the configuration, but then each MFE boots its own provider, which seems silly as each of the wrapped MFE's will have their own provider, which could be horrible when refresh tokens expire, where potentially all MFE's go off and get a new token.
• Gives me the ability to return a different auth layer for our SS rendered apps.

You could argue that "why can't the host just init the provider", well what if the host is an un-authed app, that then route transitions to an auth-required app. Seeing as that is just a react-router transition, with React.lazy, the next route could spin up a provider.

I still feel a client prop isn't a half bad idea?

---

What I'll do is; Ill spend this weekend building out exactly what our world looks like, but in that repro.

[adamjmcgrath]

I still feel a client prop isn't a half bad idea?

I'd like to avoid adding the whole client to the API (either as an initialise option or being returned from the hook). Right now the fact the SDK wraps the client is an implementation detail, we don't have to worry about what state the client is in if we create it and we don't have to worry about it's lifecycle outside of the SDK if we don't let users access it. We'd also have to deal with compatibility issues and bugs, in cases where users passed in incompatible versions of the client.

I'm happy to look at your example and see if other users have similar use cases, but I'd rather find another solution if I can.