How is this library different from another mmkv?

[Kiura]

How is this library different from another mmkv react-native library?

https://github.com/ammarahm-ed/react-native-mmkv-storage

[azeeka]

As far as I know, react-native-mmkv-storage supports encryption:

Full encryption support
The library supports full encryption on Android and iOS. You can choose to store your encryption key securely for continuious usage. The library uses Keychain on iOS and Android Keystore on android (API 23 and above). On android for lower api levels (API 22 and below), it uses secure prefrences which provides not perfect but incremental security on older Android APIs.

[mrousavy]

Originally there was only react-native-mmkv-storage by ammarahm-ed, which was a legacy bridge module (slow). At that time, I was experimenting with JSI and decided to create a new MMKV library for React Native which was way faster and synchronous by using JSI. So that's what I did, it was a lot faster and you could access all functions synchronously, so no await.
After a few weeks, ammarahm-ed apparently saw that, and also decided to migrate his library to JSI, so now the performance difference might be smaller. I noticed that a lot of his code looks similar to mine, but I don't want to make any accusations here. I do however have a way simpler interface, so to get a value you just do:

const storage = new MMKV()
const name = storage.getString('name')

Whereas with his library you kinda have this loader interface, I don't really know how this works so here's just the code taken from his docs:

const MMKV = new MMKVStorage.Loader().initialize(); // Returns an MMKV Instance 

// Then make are read/write requests

let string = await MMKV.getStringAsync("string");

So mine has a cleaner and more lightweight interface.

It's a matter of personal preference whether you would like to use my library or his.

Also:

• My library automatically installs itself, fast and lazily! The library by ammarahm-ed has a two page installation guide, with my library you don't need any of that! No need to edit native files! 🎉
• My library supports Expo :)
• My codebase is way smaller and oversee-able (matter of personal preference again).
• My library has on-value-changed listeners
• My library has Reactive-styled hooks for easy integration in function components :)
• My library is being used in lots of production apps, from my clients at Margelo, as well as in my apps. So it is also in my interest to keep this library up to date and have it working properly :)

Edit

My library now also supports

1. multiple instances
2. encryption
3. custom IDs
4. custom paths

So:

const storage = new MMKV({
  id: 'some-user-storage',
  path: ...,
  encryptionKey: ...
})

[Kiura]

Alright, now it is clear, I thought there were fundamental differences. Thank you for making this clear.

[mrousavy]

let's leave this open for future reference

[mtroskot]

I think in the best interest of RN community would be that your mmkv library and react-native-mmkv-storage merge into 1 library, since they wrap the same storage and have the same functionalities.
The end result would be a more stable library.

[The-Adult-In-The-Room]

I think in the best interest of RN community would be that your mmkv library and react-native-mmkv-storage merge into 1 library, since they wrap the same storage and have the same functionalities. The end result would be a more stable library.

Currently we get to coin-flip which one will stop maintaining their project first 😄

[mrousavy]

Well if you know my libraries, you know that I don't stop maintaining them. All of them work with the latest RN version.

Also, since I am running an app development agency, I use react-native-mmkv (and VisionCamera and others) in multiple production apps, so they work there and it's in my (and my clients') best interested to keep the maintained.

If you are missing some features or need advanced support/help, or just want to show appreciation, you can always sponsor this project. :)

[mrousavy]

Also, I'm not merging my library into his, I like my code, it's very clean and minimal. I also like my API more. And my library was using JSI first 😄

But it's always a matter of preference, you wouldn't prefer someone else's baby over yours would you?

[The-Adult-In-The-Room]

I meant no offense mate. I ended up digging through the implementation/code thoroughly before choosing your library. I've spent the last hour implementing your migration script (#52 (comment)), and refactoring the codebase (no more await for storage, yay 🎉 ). So far it's been painless and I'm thoroughly impressed with this library. Thanks for your efforts @mrousavy ! I'll consider sponsoring. 💯

[mrousavy]

Thank you Raymond, and no offense taken!

[raven619claw]

hi, first of all thanks for this great library!

I wanted to know is there any difference or security risk in providing the encryption key in JS code vs generating a random key and storing in keychain(which react-native-mmkv-storage does https://github.com/ammarahm-ed/react-native-mmkv-storage#full-encryption-support)?

[mrousavy]

Hi! Storing the encryption key in keychain seems to be a good idea, you can either manually do that or shoot me a PR so I can add it to MMKV :)