optimizely/javascript-sdk

[OptimizelyProvider UserAttributes Type Definition mismatch] The type definition for the user attributes does not match the documentation and is limiting types allowed

victor-optimizely opened this issue · 3 comments

Is there an existing issue for this?

  • I have searched the existing issues

SDK Version

3.1.0

Current Behavior

The new package has defined the UserAttributeValue to be a limited set of types which contradicts the documentation stating it supports any type. What's happening now is that if you have a custom type being set as an attribute you will receive a typescript error because the type is not supported.

Expected Behavior

The user prop in the OptimizelyProvider should allow any type definition as stated in the documentation instead of the currently defined type:

export type UserAttributeValue = string | number | boolean | null;

⬇️

export type UserAttributeValue = any;

or simply:

export type UserAttributes = {
    [name: string]: UserAttributeValue;
};

⬇️

export type UserAttributes = {
    [name: string]: any;
};

Steps To Reproduce

  • setup a project with the lastest react sdk
  • In the OptimizelyProvider's user prop, add a custom attribute that has a json value:
            <OptimizelyProvider
                optimizely={optimizelyInstance}
                user={{
                    id: profile?.id || null,
                    attributes: {
                        my_custom_attribute: { name: "something", type: "something" },
                    }
                }}
            >
                {children}
            </OptimizelyProvider>

Note the TS error:
image

React Framework

create-react-app

Browsers impacted

No response

Link

No response

Logs

No response

Severity

Blocking development

Workaround/Solution

Solution listed above. Workaround might be to ts-ignore and ensure the attribute is being used.

Recent Change

No response

Conflicts

No response

I've sent a suggestion in the Dev Docs to fix the type to match the code. Thanks for asking this question and keeping us aligned.

From PR: Our team deals with the admin center. We were setting the user's current instance object as a value here. After further investigation we are no longer using any of the fields in the object and moving forward we can just set the specific field we'll use. Since we're updating from 2.X -> 3.X a breaking change is expected I will close this in favor of the documentation being updated. Thanks for looking into it.