-
-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(NOTIFY-1146): use better type system for user storage #4907
Conversation
export enum UserStorageFeatureNames { | ||
Notifications = 'notifications', | ||
Accounts = 'accounts_v2', | ||
Networks = 'networks', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just want to make 100% sure these names are identical to what they were before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I see that account_v2 change lol.
We might not need this as we are resolving the issue through a delete endpoint.
But not against it if we want a fresh clean slate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed that they are identical! :)
I'm leaning on the side of starting from scratch after having so many devs impacted, let's keep accounts_v2
AND add a safeguard deleting possible bogus entries. I'll have a PR ready probably tomorrow about this.
UserStorageSchema[Feature][0] extends typeof ALLOW_ARBITRARY_KEYS | ||
? string | ||
: UserStorageSchema[Feature][number]; | ||
|
||
type UserStorageFeatureAndKey = { | ||
feature: UserStorageFeatures; | ||
key: UserStorageFeatureKeys<UserStorageFeatures>; | ||
feature: UserStorageFeatureNames; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be nice if some outside interfaces are backwards compatible. Supporting string unions or enums.
E.g. if I'm an SDK user, I now have to add an additional import for using user storage. That's not great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also can you make sure that we have the correct exports for the subpaths?
E.g. If I'm importing the SDK through /SDK, can I also access the enum from here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pushed a new update, making types retro compatible. Also ditched the enum for a plain old object!
So now every param could either use USER_STORAGE_FEATURE_NAMES.xxxx
or 'notifications' | 'accounts_v2' | 'networks' | ...
Explanation
This PR adds a readonly object that stores feature names so we stop relying on string values for user storage operations.
This object is also now exported from the packages, in both SDK and UserStorage paths, so it can conveniently be used in external applications.
References
https://consensyssoftware.atlassian.net/browse/NOTIFY-1146
Fixes #4921
Changelog
@metamask/profile-sync-controller
USER_STORAGE_FEATURE_NAMES
readonly objectChecklist