Skip to content
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

Merged

Conversation

Da-Colon
Copy link
Contributor

Fixes #1931

End of Series.

This adds the hook useMigrateLocalStorageV1 Which is placed inside the Providers 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 for fract_ should handle this. Thoughts?

@Da-Colon Da-Colon self-assigned this Jun 13, 2024
Copy link

netlify bot commented Jun 13, 2024

Deploy Preview for decent-interface-dev ready!

Name Link
🔨 Latest commit 367dbd6
🔍 Latest deploy log https://app.netlify.com/sites/decent-interface-dev/deploys/66706b7ad7806b0008d657b5
😎 Deploy Preview https://deploy-preview-1996.app.dev.decentdao.org
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@Da-Colon
Copy link
Contributor Author

@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

Copy link
Member

@adamgall adamgall left a 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:

  1. 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.
  2. Just a bit more abstraction please:
    • rename the hook used in Providers to useMigrate
    • the useMigrate hook checks for existence of "migration version" value
      • if no value exists
        • run the v1 migration
        • set "migration version" to 1
      • if it does exist and is >= 1, don't run the v1 migration

@Da-Colon
Copy link
Contributor Author

Two pieces of feedback, which seem in line with your thoughts too:

  1. 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.

  2. Just a bit more abstraction please:

    • rename the hook used in Providers to useMigrate

    • the useMigrate hook checks for existence of "migration version" value

      • if no value exists

        • run the v1 migration
        • set "migration version" to 1
      • if it does exist and is >= 1, don't run the v1 migration

Great ideas, I'll get on it.

@Da-Colon Da-Colon requested a review from adamgall June 13, 2024 22:43
Da-Colon added 2 commits June 16, 2024 00:28
- use import.meta.glob to get migrations
- pass count as param for testing
@Da-Colon
Copy link
Contributor Author

@adamgall Phew. Okay. I realized that I was attempting to use the filesystem (fs) which won't be available in the frontend environment. I considered using a migrations/index to get the file count but didn't like that extra overhead. After some soul searching I discovered import.meta.glob which allows you to dynamically import multiple modules based on glob patterns. This gets us the count we need.

The next problem is that this isn't mockable and since its compiled at runtime can't override it. So added a param for migrationCount that is defaulted to the globs key length, this allows me to now only mock the files in the test but pass in the count for the loop.

tests have been added.

@Da-Colon Da-Colon requested a review from adamgall June 16, 2024 14:05
Copy link
Member

@adamgall adamgall left a 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

try {
const migration = await import(`./migrations/${i}`);
migration.default();
setValue({ cacheName: CacheKeys.MIGRATION }, migrationCount);
Copy link
Member

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?

Copy link
Contributor Author

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).

Da-Colon added 2 commits June 17, 2024 00:55
- fix hoisting issues with mocks
Copy link
Member

@adamgall adamgall left a 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.

  1. gather all relevant source data
  2. use the source data to CREATE NEW keys only. NEVER modify existing localstorage keys or values in this step.
  3. 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

@Da-Colon Da-Colon requested a review from adamgall June 17, 2024 15:04
@adamgall
Copy link
Member

adamgall commented Jun 17, 2024

@Da-Colon i'm pushing one commit. then i'm good with merging 👍

edit 2 mins later: just did a force push @Da-Colon

@adamgall adamgall force-pushed the issue/1931-local-storage-migration branch from d1a0cc9 to 5626da1 Compare June 17, 2024 15:10
Copy link
Member

@adamgall adamgall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem to work any longer

Screenshot 2024-06-17 at 11 19 54 AM

I don't think it was my commit

Copy link
Member

@adamgall adamgall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LESGO

@Da-Colon Da-Colon merged commit 1411e9a into issue/1931-local-storage-updates Jun 17, 2024
7 checks passed
@Da-Colon Da-Colon deleted the issue/1931-local-storage-migration branch June 17, 2024 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants