LocalStorage polyfill

[gavrix]

AsyncStorage has always been mirroring LocalStorage from the browser. The limitations of native API, which is all native call have to be async, the storage apis transformed into async version (returning Promise<string|null> instead of string|null. And we kind of learned to live our React Native lives this way.

With the JSI and synchronous native calls now it seems that that we could actually bring API parity to storage APIs (by implementing exposing sync version of existing AsyncStorage). It could live along with existing AsyncStorage APIs to preserve backwards compatibility, something like

import AsyncStorage from '@react-native-async-storage/async-storage'
import LocalStorage from '@react-native-async-storage/local-storage'

// LocalStorage implements Storage specification https://developer.mozilla.org/en-US/docs/Web/API/Storage 

What do you think?

[krizzu]

The main reason I'm against that idea is that all IO operations should be done outside the main thread, due to obvious reasons. Having AsyncStorage synchronous you expose yourself to a jank due to it doing IO work which you have to wait to finish.

[gavrix]

I'm not following. Could you explain in a bit more detail please?
If AsyncStorage adopts turbo modules, it's bridged native calls would be replaced with jsi-bound calls but native code would still be executed on the same js thread as before. The results of operations would then be sent back via promise, which seems like

return Promise.resolve(result)

e.g. not doing anything other than skipping runloop cycle. So it makes sense to remove that Promise wrapper and return results synchronously?

[krizzu]

Sure

but native code would still be executed on the same js thread as before.

I might be reading this wrong, but you don't mean literally JS thread, but rather a thread dedicated to native modules? (asking just so we are on the same page)

So it makes sense to remove that Promise wrapper and return results synchronously?

You want to run an IO work synchronously. A work that could potentially take longer than a frame to finish. JS being single-threaded would make the whole application stop and wait for results.

We would support turbo modules eventually but would keep the asynchronous aspect with it

[gavrix]

I might be reading this wrong, but you don't mean literally JS thread, but rather a thread dedicated to native modules? (asking just so we are on the same page)

this is a good question, but let me poke around turbo modules to confirm my understanding here is correct, I'll come back with the illustration.

You want to run an IO work synchronously. A work that could potentially take longer than a frame to finish. JS being single-threaded would make the whole application stop and wait for results.

I understand AsyncStorage is more than just NSUserDefaults, however most of the time key-value storage is actually backed by NSUserDefaults and it's apis are synchronous, invoked from the main thread. That's how native iOS apps have been doing it all along. I'm advocating here to make that use-case possible.

LocalStorage apis are also synchronous in browser environment, if browsers can do that why can't we?

[krizzu]

I understand AsyncStorage is more than just NSUserDefaults, however most of the time key-value storage is actually backed by NSUserDefaults and it's apis are synchronous, invoked from the main thread

iOS version of AsyncStorage is not using NSUserDefaults, it's file-based + in-memory mix of storage, almost the same as NSUserDefaults.

Quote from iOS docs:

When you set a default value, it’s changed synchronously within your process, and asynchronously to persistent storage and other processes.

NSUserDefaults itself is sync, because it does async file writing behind the scenes.

LocalStorage apis are also synchronous in browser environment, if browsers can do that why can't we?

I would ask not if we can, but rather if we should.
An App with a blocking API in a single-threaded environment is fated to hang as I already mentioned.
You can do a simple test in browser yourself:

Type in this function in console

function showMetrics(count) {
  const start = Date.now();
  for (let i = 0; i < count; i++) {
    localStorage.setItem(`item_${i}`, i);
  }
  const stop = Date.now() - start;
  console.log(`took ${stop} ms`);
}

then run it(I used 300k as higher number is exceeding quota):

showMetrics(300_000); console.log('next line')

You'll see how much synchronous saving blocks the thread, until it executes next line. UI is not responding in that time, as it's busy executing synchronous saves.

[gavrix]

Thank you for taking time to explaining this to me! I have a better context now.
The way NSUserDefaults works (sync reads, async writes) sounds like a good way to balance between convenience and performance through. Do you think it would not be worth exploring bringing NSUserDefaults behaviour to js side?

I'm insisting on this type of APIs existing because async reads from storage leads to bad UX patterns in react environment. Effectively, any react component which relies on reads from storage would render itself twice simply because read is asynchronous (even though in majority of cases data may be available synchronously). This could be solved by pre-caching all of the storage data in-memory for sync access. It just feels that this kind of abstraction should be inside the storage library, and not fall on app developer's shoulders.