Roadmap

[ammarahm-ed]

The great thing about MMKV is that its very simple and easy to use. Also it is very fast, so I am thinking of maintaining this library here in long term which means if you are using it you dont have to worry because I will be fixing things on the way. So here is the list of things that need to be implemented if someone is interested in contributing.

v0.3.0

• Support to set int and boolean data types.
• Encryption
• Create unlimited instances of database, for example, an encrypted instance with everything important and a normal one such as app settings or something that you are storing.
• Data type Indexer
• Rewrite docs using docsify.
• Add some optimizations to give further performance boost

v0.5.0

• Rewrite using JSI without Java/ObjC Bridge
• 0.001s read/write

next v0.5.5

• Make the lib reactive to changes using Hooks & Event Listeners
• add redux-persist support
• Synchronous initialization
• Add Test Coverage

[seanyu4296]

Hi, i am actually interested in using this library in my project. Just wondering, how are you planning to implement "Make the lib reactive to changes using Hooks & Event Listeners"? maybe i can give it a shot.

Some questions:

1. will the logic be every change in some react "state" call setItemAsync? and getItemAsync on initial load of app? or we can directly read from mmkv like its in memory to make it "reactive"?
2. are there event listeners built in mmkv then we expose it to the js side?

[8BallBomBom]

Any plans to get the min sdk version for android down to 16?
MMKV itself has 16 as a min sdk version.

Currently a deal breaker as we're trying not to lose older android support for a while.

[ammarahm-ed]

@8BallBomBom try the latest version.

[8BallBomBom]

Thanks, will give it a bash 👍

Also any plans to replace this with this?
Deprecation has settled in and it looks like a straight change over.
Would be a breaking change for existing users though unless using the same encryptions and such.
They pretty much both wrap Shared Preferences.
Could be a nice future improvement :)

[ammarahm-ed]

@8BallBomBom there are no such plans. The library is used only for older version of android that do not include a keystore. i.e API 22 and older versions. There is no perfect solution for older android versions since latest security patches are not available. If someone is using an old version of android, its itself a security risk for losing data etc. The library provides enough security to fill the need to some degree.

For newer android versions, Android Keystore is used.

[8BallBomBom]

No worries, just figured could be a good alternative to fill in the gap and get rid of anything deprecated, the functions etc are the same as it is just another wrapper.

Gonna be looking to use this library now so there is a chance i might put in a pr for that ^

[ammarahm-ed]

EncryptedSharedPrefrences basically uses Android Keystore System to save the master key.

This library is already using Android Keystore System (sdk 23 and above) to store the passwords etc so I think does the job. Rest of the things are stored in mmkv.

The secure prefrences library is for sdk 23 and lower where Android Keystore or EncryptedSharedPrefrences are not available to use.

[8BallBomBom]

Ahhhhh i couldn't see the sdk version, assumed it was viable to use on older versions of Android.
No worries :)

[ammarahm-ed]

@seanyu4296 Thank you for showing interest in the library. Reactivity means that when you set a new value for key x, its value in memory will be updated to the new value in all the components it is being subscribed in. The functionality would be similar to a state management library but the difference would be that all changes will not only be in memory on writing but also stored to database.

Here are somethings we would need to do for the process:

1. User of the library needs to define a Schema, which means telling the library what items need to be reactive. For example we have a object:

var fruits = {
    "apple":1,
    "orange":2
}

Now maybe I only want to update my component when apple changes in the fruits object. For that a schema should be defined by the user so the library would know when to update the component using a Hook call.

export const FruitSchema = {

"apple":true,
"orange":false

}

A hook can be like this

const fruits = useMMKV(db => db.fruits);

Now to component would be updated when apple changes in fruits. For simple variables like a string, bool, number etc a simple schema would be needed that would help us identify what changes are to be listened overall.

There are no event listeners in MMKV built in, but we can make some that help us, event listeners can be made on the JS side or on Native, both would work in a similar way. I think JS would be easier to manage. We don't have to worry about writing data since all data writes are synchronous in MMKV.

I hope this information will be helpful for you.

[seanyu4296]

got it. thank you for expounding! @ammarahm-ed your proposed solution seems promising maybe i can give a helping hand when you start working on it i dont have a deep knowledge of MMKV :)

A side question: do you know if MMKV supports locking?

[ammarahm-ed]

@seanyu4296 what do you mean by locking?

[seanyu4296]

Oh my bad for the vague question. does MMKV have db transactions? @ammarahm-ed

[ammarahm-ed]

@seanyu4296 I do not think it does since all the changes are instantly written.

[seanyu4296]

I see thank you for sharing your knowledge! just a background, i have a headless js that spins up by an android service, and i think i might have a race condition on reading and writing.

[luism3861]

amazing library thanks!.

[hannojg]

I think making use of new turbo modules architecture (JSI in particular), as react-native-leveldb does, would be great here. Then this library would be without any doubt the fastest storage solution for RN. Through this re-architecture, there would be no communication over the JS bridge.

[ammarahm-ed]

@hannojg Thanks for the lovely comment. I will look into it and see how we can use turbo modules to make this the fastest. It is still quite fast but there is always room for more improvement. If you find any other related resources, you can send them here

[ammarahm-ed]

@hannojg done!

[likern]

@ammarahm-ed Hello 👋 Can you compare with https://github.com/mrousavy/react-native-mmkv? Is there any difference in performance / stability?

[ammarahm-ed]

@likern No noticeable difference in performance. As far as stability is concerned, this library has a few bugs still. I do not know about the one you mentioned.

The reason is that JSI is not released by react native community yet, there are no docs or guides on how to build native modules.

Until version 0.4.4 the library does not use JSI and still is performant than most libraries out there without JSI.

[ammarahm-ed]

Starting from v0.5.5 enjoy Reactivity with useMMKVStorage Hook! 🚀

[sektr63a]

Any plans to make clearStore, removeItem as sync?

[ammarahm-ed]

Any plans to make clearStore, removeItem as sync?

Yes, they can be sync, hopefully in v0.5.7. We just need to change handleActionAsync to handleAction and remove await

[SaltedBlowfish]

@ammarahm-ed One opinion I have from implementing this package is that the useMMKVStorage hook doesn't reflect the expectation of the "setter" portion of the React built-in state hooks. It's not documented that it should, but just a thought here...

Ideally, we would be able to have a state change with a previous value provided, similarly to the React.useState hook for making sure value writes are happening without overwriting previous states:

React's API

const [value, setValue] = React.useState(0);
...
setValue((prev) => {
  // we have access to prev in here for making safe changes to the state
  return prev + 1
})

RN MMKV's API

const MMKV = new MMKVStorage.Loader().initialize();
const [value, setValue] = useMMKVStorage('counter', MMKV);
...
setValue(
  // cannot be a function that accepts previous state
)

Adding this to the roadmap would be awesome. Your package is a huge boon to the React Native community.

[ammarahm-ed]

@ammarahm-ed One opinion I have from implementing this package is that the useMMKVStorage hook doesn't reflect the expectation of the "setter" portion of the React built-in state hooks. It's not documented that it should, but just a thought here...

Ideally, we would be able to have a state change with a previous value provided, similarly to the React.useState hook for making sure value writes are happening without overwriting previous states:

React's API

const [value, setValue] = React.useState(0);
...
setValue((prev) => {
  // we have access to prev in here for making safe changes to the state
  return prev + 1
})

RN MMKV's API

const MMKV = new MMKVStorage.Loader().initialize();
const [value, setValue] = useMMKVStorage('counter', MMKV);
...
setValue(
  // cannot be a function that accepts previous state
)

Adding this to the roadmap would be awesome. Your package is a huge boon to the React Native community.

That is surely possible and would be great addition. I will add it in next release. If you have time, you can also send a PR. The useMMKVStorage code is straight forward.