feat: added support for async-storage-plugin

[kagrawal61]

Description

This PR introduces a new AsyncStorage plugin for Rozenite, providing comprehensive inspection and management capabilities for AsyncStorage data within React Native DevTools.

Features

• Real-time Storage Inspection: View all AsyncStorage entries and their contents in real-time
• Data Type Detection: Automatically detects and displays different data types (string, number, boolean, object, array)
• Search & Filter: Quickly find specific keys or values with real-time search functionality
• Data Management: Add, edit, and delete entries directly from the DevTools interface
• Visual Data Representation: Color-coded type indicators and formatted value display

Testing

The plugin has been tested in the playground app with various types of data stored in AsyncStorage, including strings, numbers, booleans, objects, and arrays.

How to use

// App.tsx
import AsyncStorage from '@react-native-async-storage/async-storage';
import { useAsyncStorageDevTools } from '@rozenite/async-storage-plugin';

function App() {
  // Enable AsyncStorage DevTools in development
  useAsyncStorageDevTools(AsyncStorage);
  
  return <YourApp />;
}

Dependencies

• Requires @react-native-async-storage/async-storage as a peer dependency

Visuals

[vercel]

@kagrawal98 is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

[V3RON]

I wonder if it would make more sense to generalize the MMKV plugin so that it accepts any kind of storage conforming to a Storage interface, and then provide adapters for MMKV, AsyncStorage, or any other storage solutions. That way, one could write:

useStoragePlugin({
  adapters: [
    mmkvStorageAdapter([mmkvOne, mmkvTwo]), // Wraps MMKV so it conforms to the interface
    asyncStorageAdapter(AsyncStorage), // Accepts an instance, so we’re not tightly coupled to one particular AsyncStorage implementation
  ],
});

WDYT?

[kagrawal61]

I wonder if it would make more sense to generalize the MMKV plugin so that it accepts any kind of storage conforming to a Storage interface, and then provide adapters for MMKV, AsyncStorage, or any other storage solutions. That way, one could write:

useStoragePlugin({
  adapters: [
    mmkvStorageAdapter([mmkvOne, mmkvTwo]), // Wraps MMKV so it conforms to the interface
    asyncStorageAdapter(AsyncStorage), // Accepts an instance, so we’re not tightly coupled to one particular AsyncStorage implementation
  ],
});

WDYT?

@V3RON Thanks for the suggestion — I think that makes a lot of sense 👍.
A unified storage plugin with adapters feels like a cleaner long-term direction. That way we keep one DevTools panel for “Storage” but still support multiple backends (MMKV, AsyncStorage, etc.) without duplicating the UI.

At a high level, the structure could look like:

• storage-core: defines the StorageAdapter interface, shared bridge/events, and a generic useStoragePlugin.
• Adapters: thin packages like mmkvStorageAdapter(mmkvInstances) or asyncStorageAdapter(AsyncStorage) that implement the interface. Any backend-specific utils (e.g., listeners, serialization) live here.
• Wrappers (for back-compat): existing useMMKVDevTools() and useAsyncStorageDevTools() would just call into the core with their adapter, so we don’t break current users.

UI-wise, we could have a single “Storage” panel with tabs or a scope switcher inside for each adapter/instance. That keeps things discoverable, but also lets users work with a specific store when they need to.

Happy to start by landing the AsyncStorage plugin as a separate wrapper and then refactor toward this core+adapter setup if that sounds like a good path forward ?

[github-actions]

This pull request has been marked as stale because it has been inactive for 30 days. Please update this pull request or it will be automatically closed in 14 days.

[V3RON]

Sorry for the long delay @kagrawal61!

Happy to start by landing the AsyncStorage plugin as a separate wrapper and then refactor toward this core+adapter setup if that sounds like a good path forward ?

Do you mean you'd like to release this new plugin and then deprecate it in favor of a more 'generalized' one? Personally, I'd prefer refactoring the existing mmkv plugin to use this architecture and then renaming it. That way, we'd have a single codebase, and we wouldn't need to keep both in sync whenever something changes.