feat(core): Introduce new API

[krizzu]

Summary

This is an introduction to AsyncStorage v2. This is by no means the final shape, just something to spark a discussion.

Glossary

• Core - Unified and concise API, extending Web Storage API with additional methods for multi-key manipulations. The main instance, AsyncStorage, is created by connecting it to a StorageBackend via call to AsyncStorageFactory.create

• StorageBackend - Backing storage engine used by AsyncStorage instance. It provides basic methods to read/save and remove data. If the storage provides more capabilities than required, it can be exposed via Extension. The storage works on already serialized data (string).

• Extension - additional functionality provided by StorageBackend on top of standard capabilities. This is heavily influenced by the capabilities of StorageBackend itself. One example could be providing information about storage size on disk.

• Adapter - Serializes and deserializes provided data, before passing it to/from StorageBackend. As for now, a no-op adapter is used. In future versions, a user could provide their own StorageModel type and an Adapter for it (think of skipping all JSON.stringify/JSON.parse calls.

Main changes

API separation

To expand AsyncStorage into different use cases, the storage has been separated from the core API. This means, that while the main API stays the same, the underlying storage engine will provide different capabilities, depending only on the implementation. From a user perspective, one API can be used to use different kinds of storage, such as file-on-disk, in-memory, SQLite, Encrypted, etc.

Getting AsyncStorage

Because of the separation, the main instance, AsyncStorage needs to be connected to StorageBackend. This happens via call to AsyncStorageFactory.create method, where user needs to provide an instance of StorageBackend.

[krizzu]

After giving it some more thought, I became more sceptic about this approach. There is a shortcomings that I think blocks AsyncStorage from moving into the "next" stage.

AsyncStorage is working on serialised data, only. That means, it accepts and returns strings and leave serialization to the user. In this PR, you can see added "Adapter" acting as a middleware responsible for just that , an attempt to improve the developer experience.
At that point, I think it's a workaround, rather than a solution, because we force this limitation on StorageBackends (force them to work on strings), rather giving them a freedom to choose.

With TurboModules, we have access to bridging functionality, which could omit serialization (to some extent) on JS thread, improving performance. Good example of this is MMKV storage.

I think it's worth re-thinking a reason to have StorageBackend all together. I think exposing an AsyncStorage interface and let storages implement it in their way (with flexible Storage Model) would be better approach. WDYT?

[krizzu]

See #1016