Skip to content

[BUG] OptimizelyProvider overwrites user set via setUser with default user unless passed via user prop #286

Closed
@dnedo

Description

@dnedo

Is there an existing issue for this?

  • I have searched the existing issues

SDK Version

3.2.2

Current Behavior

After upgrading to v3 of the Optimizely React SDK, rendering OptimizelyProvider after setting a user via setUser overwrites the previously set user with a default one, unless the user is explicitly passed to the provider via the user prop.

Expected Behavior

In our app, we handle Optimizely initialization and set the correct user ID and attributes outside the React lifecycle. Some of our initial decision calls may occur before the React tree is rendered, which is why we call setUser as early as possible. Our user object is also independent of the React lifecycle, which is why we've avoided passing it directly to the provider.

Is managing user outside of the React lifecycle not supported anymore? We would expect OptimizelyProvider to respect the previously set user and avoid overwriting it if the client already has a user set.

Steps To Reproduce

const optimizelyClient = createInstance({ sdkKey: "key" });

optimizelyClient.setUser({ id: "unique_id", attributes: { a: 1, b: 2 } });

// at this point, inspecting optimizelyClient.user shows the values have been set correctly
console.log(optimizelyClient.user);

function App() {
  useEffect(() => {
    // at this point, inspecting optimizelyClient.user shows the previously set values have been overwritten by OptimizelyProvider
    console.log(optimizelyClient.user);
  }, []);

  return (
    <OptimizelyProvider client={optimizelyClient}>
      <AppContent />
    </OptimizelyProvider>
  );
}

React Framework

react-native 0.74.5

Browsers impacted

No response

Link

No response

Logs

No response

Severity

Blocking development, Affecting users

Workaround/Solution

Add an additional check to the final else branch inside OptimizelyProvider's setUserInOptimizely method here:

} else {
that would prevent it from falling back to the default user if there's already a non-default user set in the client.

Recent Change

#229

Conflicts

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions