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

debt: need to change KV storage library #2842

Closed
shrouxm opened this issue Jan 23, 2025 · 0 comments · Fixed by #2845
Closed

debt: need to change KV storage library #2842

shrouxm opened this issue Jan 23, 2025 · 0 comments · Fixed by #2845

Comments

@shrouxm
Copy link
Member

shrouxm commented Jan 23, 2025

We are currently using https://github.com/ammarahm-ed/react-native-mmkv-storage. We've experienced a lack of responsiveness to bug reports with the maintainer:

and are now blocked from upgrading to expo 52 and react native 0.76 because of this.

I see two potential options for other libraries to use:

Switching to the Expo SQLite library seems more desirable to me:

  • it reduces the number of organizations we rely on for our dependencies
  • we know that the Expo people can be reached via office hours and will take care of critical bugs promptly
  • it has some bells and whistles (on-device database browser seems nice)
  • it makes a SQLite database available in our app in case we ever want to use one
  • it's based on SQLite, the most widely used database in the world

Switching to the other MMKV library would mainly be desirable because:

  • it'd be easier
  • it has better performance (switching to sqlite might make our KISS strategy of synchronously writing the whole redux store to disk on each redux update less do-able)

But we're less likely to encounter any incompatibilities switching to the other MMKV library. It's possible the only reason we didn't take this approach initially is because the expo integration didn't exist previously.

Migration implications

This changeover could be done in two ways:

  • phased transition, where we try to preserve the contents of users' local databases by having two libraries installed at once and writing migration code. this is more effort (probably makes this a 7+ instead of a 3)
  • hard transition. this is easier, but has the following user-visible implications:
    • users will be logged out of the app
    • unsynced soil data stored on users' devices could be lost
    • users will be shown the interstitial again
@shrouxm shrouxm added this to the LandPKS Backlog milestone Jan 23, 2025
@shrouxm shrouxm added this to LandPKS Jan 23, 2025
@github-project-automation github-project-automation bot moved this to Todo in LandPKS Jan 23, 2025
@shrouxm shrouxm self-assigned this Jan 24, 2025
@shrouxm shrouxm moved this from Todo to In Progress in LandPKS Jan 24, 2025
@shrouxm shrouxm moved this from In Progress to In Review in LandPKS Jan 25, 2025
@github-project-automation github-project-automation bot moved this from In Review to Done in LandPKS Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants