-
Notifications
You must be signed in to change notification settings - Fork 7
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
1931
local storage migration
#1996
1931
local storage migration
#1996
Conversation
- delete other cache
- added conditionals to ensure proper handling of cache
✅ Deploy Preview for decent-interface-dev ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@decentdao/engineering Since this is kinda hard to test (I guess you can add a old favorite cache manually in the deploy preview), I added a test and some test cases for it to make sure this works as expected |
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.
Two pieces of feedback, which seem in line with your thoughts too:
- Yes, let's set up the structure now for multiple migrations. I do think adding a "migration version" to local storage is a good idea at this point.
- Just a bit more abstraction please:
- rename the hook used in
Providers
touseMigrate
- the
useMigrate
hook checks for existence of "migration version" value- if no value exists
- run the
v1
migration - set "migration version" to
1
- run the
- if it does exist and is >=
1
, don't run thev1
migration
- if no value exists
- rename the hook used in
Great ideas, I'll get on it. |
- use import.meta.glob to get migrations - pass count as param for testing
@adamgall Phew. Okay. I realized that I was attempting to use the filesystem ( The next problem is that this isn't tests have been added. |
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.
Love the tests. Have one question about a small thing, but otherwise looks great
src/hooks/utils/cache/useMigrate.ts
Outdated
try { | ||
const migration = await import(`./migrations/${i}`); | ||
migration.default(); | ||
setValue({ cacheName: CacheKeys.MIGRATION }, migrationCount); |
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 don't think this is correct. Inside each loop iteration, we should set cacheName
to i
, right?
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.
That is correct. left in a change during testing. Updated that. I also went ahead and removed the localStorage update from the loop. I'd rather do that once on a success or failure.
I also went ahead and added another test for the runMigration
button for a successful run (only had error states tested).
- remove setValue from loop;
- fix hoisting issues with mocks
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.
Found a bug or two.
And then I have yet other idea about the migration code. should it perform some self-tests?
// dev: as i wrote out the below, proper implementation became more unrealistic with each line. keeping for posterity, but these are just the ramblings of a dreamer for now
For example, consider each migration file was split into 4 distinct steps.
- gather all relevant source data
- use the source data to CREATE NEW keys only. NEVER modify existing localstorage keys or values in this step.
- run tests... make sure new data looks like it should look like, considering the source data.
a. if the tests don't pass then throw an error or something. DON'T DELETE source data or the invalid new data.
b. if they do pass, update migration
d1a0cc9
to
5626da1
Compare
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.
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.
LESGO
Fixes #1931
End of Series.
This adds the hook
useMigrateLocalStorageV1
Which is placed inside theProviders
component (at top of tree).This hook is called when keys that include
fract_
for V1 are found. filters for Favorites and combines the networks into a single favorites cache adding the network prefix for network of the favorite.It then removes all old
fract_
keys from local storage clearing out the old cache.Thoughts
I thought about adding a
V1_MIGRATION
: true to local storage then use that to make sure this didn't run after running. but felt the search forfract_
should handle this. Thoughts?