feat: add in-memory storage as a fallback for disabled LocalStorage

[jpudysz]

Hello @mrousavy ✋

I am submitting this pull request to propose the addition of a new feature webFallbackStorage. The purpose of this enhancement is to provide a more resilient storage option for web environments, particularly when users disable localStorage in their browsers.

The webFallbackStorage is designed as an optional property that conforms to the Storage type. It allows the application to handle disabled localStorage situations gracefully by offering eg. in-memory storage as an alternative. This ensures smooth functioning of the application despite any user-imposed limitations.

Right now, react-native-mmkv throws an error and there is no way to run the monorepo with disabled localStorage.

Here's a brief overview of the changes introduced with this feature:

• The webFallbackStorage property has been added as an optional attribute, maintaining backward compatibility with existing implementations.
• When a user disables localStorage, the application will seamlessly transition to using webFallbackStorage, ensuring no disruption in the user experience.
• If the webFallbackStorage property is not provided, the default behavior remains unchanged, and an error will be thrown in case localStorage is disabled.

I believe this enhancement will significantly improve the robustness and flexibility of the react-native-mmkv library.
Later we can add default in-memory storage to the lib.

Please feel free to reach out to me with any questions or suggestions.

[jpudysz]

This is default behaviour:
White screen + such error message in the console:

[mrousavy]

hey! thanks for your PR man! Left some comments, lmk :)

[jpudysz]

Ready to be checked @mrousavy

We have a single warning and my app is up and running 🪄

[jpudysz]

@mrousavy is there anything I can do with failed job?

[mrousavy]

Hey - for some reason the linter failed. I'll fix that, your PR looks good!

I'm thinking if we should also use the in-memory Map fallback for when JSI is unavailable, e.g. when running in a Chrome debugger?

[jpudysz]

Hey - for some reason the linter failed. I'll fix that, your PR looks good!

I'm thinking if we should also use the in-memory Map fallback for when JSI is unavailable, e.g. when running in a Chrome debugger?

If it causes a crash then yes, it's still better to have limited experience, yet let the user debug the app.

[hirbod]

Hi @jpudysz @mrousavy,

while this PR is great and works as expected inside the browser, it does flood and spam the Next.js server console now.
We're using server side props / rendering, which does not have access to window.localStorage, but the client has access.

This is throwing an incredible amount of console.log's now while navigating for us.

[hirbod]

I think the console.log should only be printed if typeof window !== "undefined"