Request: Expose LDProvider as a component in addition to the higher-order component.

[threehams]

Is your feature request related to a problem? Please describe.
The provider is currently exposed as a higher-order component, with configuration supplied through an argument which can only accept a user available as a global. I'm currently in the process of setting up our layout component with hooks (react-cookies), and unfortunately, the user ID we need is only available from an API call. We're currently looking at adding this to the session cookie, but even then, it's going to involve imperative document.cookie calls - something we're avoiding in favor of universally SSR-safe cookies through context.

Describe the solution you'd like
Expose a new LDProvider component export, which is just these lines extracted to a new file, and this line moved inside the provider.

Describe alternatives you've considered
Imperatively access document.cookie instead of using useCookie() or any other client-only method for accessing cookies, with all checks for typeof window.

There doesn't appear to be any solution for dynamic user IDs outside cookies or other global storage.

Additional context
This was suggested in #166 previously, though that was in the context of switching users; this is about initialization without later changes. Allowing user to be a prop could lead to confusing behavior, as changing user will not really have any effect without further changes.

The HOC prevents the userId from changing after initialization, but with the negative effect of interop with other libraries.

Since ldClient is within scope of the provider code, it should be possible to listen to updates of user and call ldClient.identify whenever a change occurs.

I can make this change, if it's accepted.

[yusinto]

Hi @threehams thanks for raising this issue. This is a good point and it's something we will officially support both in the base js sdk and in react sdk. The first step we'll take is to support a getter method to get the ld user from the base js sdk. We will then subsequently implement a user prop which will be available via the react sdk so consumers can subscribe to user changes.

We'll add this to our backlog so unfortunately I can not give an exact eta at this point in time.

[eli-darkly]

Closing this because 1. I think it has already been addressed in the React SDK, and 2. if it hasn't, the place to discuss that is in the issues for https://github.com/launchdarkly/react-client-sdk, not js-client-sdk.