[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
userprop, 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>
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.
