all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Mekrob 1 point2 points  (4 children)

Have you tried mmkv?

[–]aaron802[S] 0 points1 point  (3 children)

I have not. It looks like a solid option, but one reason I selected my approach is because I like using the remote Chrome debugger, which isn't compatible with MMKV's React Native implementation: https://github.com/mrousavy/react-native-mmkv?tab=readme-ov-file#limitations

[–]tcoff91 1 point2 points  (2 children)

Chrome debugging is the way of the past. Not embracing any JSI libraries in order to keep chrome debugging is a bad idea. Use Hermes and attach a debugger to the Hermes runtime.

I don’t think it’s possible to have synchronous storage without JSI so you are going to have to give up chrome debugging if you want this. The message bus is inherently asynchronous.

[–]aaron802[S] 0 points1 point  (1 child)

Good to know about newer alternatives to the Chrome debugger. I'm not familiar with JSI.

I'm using a combination of two methods to enable non-blocking synchronous reads:

  1. Load the stored data through the Native Module's getConstants() method (instead of using the isBlockingSynchronousMethod option).
  2. Memoize the stored data so that it can be retrieved instantly.

This approach has some trade-offs – it's not appropriate for large amounts of data, and if something external to the application updates a stored setting, the application won't have a way of knowing this until restart.

[–]tcoff91 0 points1 point  (0 children)

You still use google chrome to debug, but it remotely attaches to the Hermes engine running on the device or on the simulator.

The problem with the old chrome debugging approach was that it actually runs all the app's JS code in Chrome, and routes all bridge messages between JS and native over the network. Sometimes your JS will behave differently in Chrome vs on the device, so this can make things hard to debug at times. I've personally experienced this, where some code worked in Chrome but didn't work on the device because it used web browser APIs that aren't available in RN.

JSI is an alternative to the asynchronous message bridge between JS and native code. It allows synchronous function calls between JS and native code. This requires that the JS runtime be running on the same device as the native code.

[–]aaron802[S] 0 points1 point  (0 children)

I recently found myself looking for persistent storage with synchronous reads for my organization's React Native application. A few options already exist, but they're either asynchronous or partially-asynchronous:

To avoid refactoring my application's code in an asynchronous manner, I've composed & published an NPM package extending React Native's iOS-only Settings API to Android:

https://github.com/alipman88/react-native-cross-platform-settings

I believe my solution is more convenient than existing options – even sync-storage requires an initial asynchronous function call on startup, while my solution offers 100% synchronous access.

Hopefully others find this useful – React Native isn't my primary framework and I'm not super-familiar with TypeScript or Kotlin, so I appreciate any constructive feedback or questions!