react-oidc-context
react-oidc-context copied to clipboard
auth provider props and user manager settings have incompatible types
after upgrading there is a mismatch between the 2 types of usersettings and authprovider props because of of the following change
export declare interface AuthProviderUserManagerProps extends Omit<AuthProviderPropsBase, "redirect_uri" | "client_id" | "authority"> { redirect_uri?: never; client_id?: never; authority?: never; }
I'm not quite sure what was the point of this change, would be very happy for an explanataion:) so i can change accordingly.
The idea was to not have both userManager and redirect_uri + client_id + authority. In case you use the later one you can use in you application the type AuthProviderNoUserManagerProps.
I am not very happy with the current definition of this! The combination type export type AuthProviderProps = AuthProviderNoUserManagerProps | AuthProviderUserManagerProps; does not behave as expected: Accept either the first or second definition, but not both. Any better solution?
~~One alternative could be to just log a warning in case userManager an a userManager settings is provided together. Probably much simpler. Other ideas?~~
type-wise the modification of the AuthProviderProps was a breaking change, sorry about that.
It would have been better to keep AuthProviderProps exactly the same, namely without optional userManager. But now that we have it, I will keep that and do not change it again...
The idea was to not have both
userManagerandredirect_uri+client_id+authority. In case you use the later one you can use in you application the typeAuthProviderNoUserManagerProps.I am not very happy with the current definition of this! The combination type
export type AuthProviderProps = AuthProviderNoUserManagerProps | AuthProviderUserManagerProps;does not behave as expected: Accept either the first or second definition, but not both. Any better solution?
I'll have to think of a solution. in general for me it was comfortable that I was able to instantiate usermanager without the context and with the context using the same type depending on how the page loads. as a general sense I think typing should reflect the code behavior as much as possible is there a benefit to enforce you cannot pass the extra params to props?
I have improved the current solution in the MR #528.
I took a look now and it's understandable, thanks have a nice day