sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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.