Suppor for React Native Web

[sreuter]

Checklist

• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

React Native Web is commonly used these days along the Android & iOS targets. It would be awesome if this library could support it as well, so users wouldn't need to handroll their own solution for the web target.

Describe the ideal solution

A developer can use this library for React Native Web, iOS & Android.

Alternatives and current workarounds

Handroll your own solution for React Native Web.

Additional context

No response

[poovamraj]

Hi @sreuter Thanks a lot for raising this.

We had plans to support this but de-prioritized considering this is not an official support. However we are very interested in knowing what the community thinks and we would be happy to support if there is enough demand for the feature.

Do feel free to add more to the discussion. We will leave this issue open to get more feedback from the community

[KMathisGit]

We had plans to support this but de-prioritized considering this is not an official support. However we are very interested in knowing what the community thinks and we would be happy to support if there is enough demand for the feature.

What exactly do you mean by "this is not an official support"?

I agree with @sreuter on this. Web for React Native is becoming more and more a common target as the Web support has got better in recent times. Not to mention Expo's new router really makes the web an even more viable option with file-based URL routing and SEO concerns being addressed.

This is surely going to be requested more moving forward. Sounds like you all were already kind of planning on it being one, but have decided against it for the time being, I'd recommend to re-visit it.

[Jackman3005]

@poovamraj it's strange this isn't official support since react for web is and react-native is, react-native web is just react for web at the end of the day, it just needs to be integrated into the react-native-auth0 library and used when on the web platform. The common pattern to resolving this ourselves in React Native Web projects is to include both the react-native-auth0 and @auth0/auth0-react libraries and try to create our own "generic" API that lets us interact with the correct Auth0 library for the platform (native/web). Since the contexts provided by these two libraries are rather different this is challenging and has required some hacks to get it to work well. Likely each of us that has done this has built a different "generic" API based on our needs/understanding. This is something that should be provided by Auth0 and community driven.

Using Expo snack to test this Auth0 library will not work by default since Web is the default platform in the most common tool for providing Expo project snippets...

[poovamraj]

Thanks a lot for the valuable feedback @KMathisGit @Jackman3005. We were looking forward to such conversation with the community before providing support for Web in React Native.

@Jackman3005 can you provide a sample or overview of how you achieved the solution

@KMathisGit If you can elaborate on the issues you are facing it would help us understand the issues faced by the community.

[Jackman3005]

@poovamraj Sure. Essentially I created two files called Auth0Provider.tsx (for native) and Auth0Provider.web.tsx (for web) in my project. These files import the platform specific Auth0 libraries: react-native-auth0 for native and @auth0/auth0-react for web and act as an adapter to create a common interface for the application to work with.

These files export a Context Provider. The Context is a common interface to accomplish my application's goals without knowing whether we are working with the native or web implementations of Auth0.

Here are the types for the common Context that my application consumes:

export type LoginAppState = {
  url?: string;
  identifier?: string;
  priorLogin?: {
    accessToken: string;
  };
};
export type IAuth0Context = {
  openAuth0UniversalLogin: (options: {
    appState: LoginAppState;
    identifierHint?: string;
    connection?: string;
  }) => void;
  isAuthenticationResultAvailable: boolean;
  getUniversalLoginResult: () => Promise<
    UniversalLoginError | UniversalLoginSuccess
  >;
  logoutAuth0: (redirectPath?: string) => Promise<void>;
};
export type UniversalLoginError = {
  success: false;
  error: unknown;
};
export type UniversalLoginSuccess = {
  success: true;
  accessToken: string;
  refreshToken: string;
  savedAppState?: LoginAppState;
};

Please note that I am not suggesting this library implement the interface exactly as I have done here, but rather this is just an example of what I've had to go through to create a common interface for my application to work with Auth0 both on Native and Web. Note that Auth0Provider.tsx is ~120 lines of code and Auth0Provider.web.tsx is ~200 lines of code.

My implementation only covers aspects of the Auth0 implementations that I needed access to and I imagine a complete solution would contain this and more code. Alternatively the libraries could adjust their current APIs to be more similar to one another and it would reduce the work needed to manually massage them into a common format.

[KMathisGit]

@KMathisGit If you can elaborate on the issues you are facing it would help us understand the issues faced by the community.

The issues I face are the exact same as those that @Jackman3005 has elaborated on. Since we target both platforms (web and native mobile) we need to create our own abstraction layer that will handle which package to use based on current platform.

From a consuming perspective of the package it really feels like it ought to be baked in. No good reason that consumers should have to create their own abstraction layer for something as common as wanting to use auth0 across both platforms.

[poovamraj]

Thanks for the suggestions @Jackman3005 @KMathisGit. We will keep this thread open to hear more from our community and I will notify here on how we are planning to proceed ahead.

[steventnorris]

I am about to need to implement a similar solution as Jackman3005 did. Our client is using RN with RNW for cross-compile. Would love to just use the RN package for Okta here with an officially supported implementation. +1

[Katerlad]

Also needing to roll my own abstraction layer, to detect the platform the client is on. Very Annoying. +1 from me to please add this support.

To pass along some feedback, it would be very nice if your quick start guides for both EXPO and React Native Mention a section for "Web" currently only IOS and Android are even mentioned on how to set it up. A warning disclaimer or, a section labeled "Web" with details stating it is not currently supported would save your customers time on looking up why it isnt working out of the box! :)

[brushton-ces]

@poovamraj any update on roadmap for this? Is this something we might expect sometime soon?

[poovamraj]

@kevlil83 will be providing an update over this soon in the thread.

[gfriedm4]

@poovamraj @kevlil83 Any update on this? We are also doing a mixture of what is said above (separate handling of web and native in a wrapper component), but would love to consolidate.

[ThomasGHenry]

@poovamraj ?

[driscollwebdev]

Count me as another developer facing this issue who'd like to see a solution asap.

[krolow]

have this been addressed? Im looking for such a solution as well

[brth31]

Apologies for the radio silence here. We are planning to support this along with other improvements in the next major release coming up this quarter. I'll share exact timelines by the mid of June.

cc: @sreuter @Jackman3005 @KMathisGit @brushton-ces @gfriedm4 @ThomasGHenry @driscollwebdev @krolow @steventnorris @Katerlad