Borrado del almacenamiento y estrategias de migración

As your app evolves across versions, the data structure you store in AsyncStorage may change. Old data from previous app versions might not match what the new code expects, leading to crashes or incorrect behavior. A solid storage maintenance strategy — including selective clearing and versioned migrations — is essential for apps that have real users with existing data.

AsyncStorage.multiRemove accepts an array of key strings and deletes all of them in a single operation. This is more efficient than calling removeItem repeatedly in a loop. Use it when a user action should clear a specific subset of data — for example removing all cached API responses without touching user preferences.

AsyncStorage.clear() removes all keys stored by the app. Use this only for destructive operations like a factory reset or during development when you need a clean slate. In production, always confirm with the user before calling clear() because it cannot be undone and deletes everything — preferences, cached data, and auth tokens alike.

When you store data with dynamic keys (like post_123, post_456), use getAllKeys to find them and filter by a prefix before passing the matching keys to multiRemove. This pattern is useful for clearing all cached pages from a paginated feed without hardcoding each key.

A storage migration upgrades stored data from one schema version to a newer one. When you release a new app version that changes how data is stored — for example renaming a key or adding a required field — migrating existing users' data prevents crashes and data loss. Migrations run once on startup and mark the completion with a version flag.

Store a schema version number in AsyncStorage alongside your data. On startup, read this version number and compare it to the current expected version. If they differ, run the appropriate migration steps, then update the stored version number. Future launches skip the migration because the versions match.

Write a migration function that handles each version upgrade step. Use a switch statement or a series of if checks that fall through from the stored version up to the current version. Each case applies the changes needed to advance one version, so a user upgrading from v1 to v3 runs both the v1-to-v2 and v2-to-v3 migrations in sequence.

Call the migration logic in your root component's useEffect before anything else reads from storage. This ensures all data is in the expected shape before any screen tries to use it. Keep migrations idempotent — running them twice on the same data should produce the same result to handle edge cases like interrupted writes.

Cache data should not live forever. Store a timestamp alongside cached API responses and check whether it has expired when the app starts or when the user navigates to a screen. If expired, delete the cache and fetch fresh data. A helper function that wraps the cache check makes this reusable across all cached endpoints.

When a user logs out, clear their personal data (auth token, profile, private cache) but preserve device preferences like theme and language. Use multiRemove with a specific list of keys rather than clear(). This provides a better UX because the user's display preferences are still there when they log back in.

Maintain a storage schema documentation file in your project that lists every AsyncStorage key, its type, its default value, and which version it was introduced. This is invaluable when writing migrations, debugging storage issues, and onboarding new developers. Treat it like a database schema — update it every time you add, rename, or remove a stored key.

In this lesson you learned: multiRemove efficiently clears a specific set of keys while leaving others intact, versioned migrations upgrade old stored data when the app schema changes across releases, and expiring cached data with timestamps prevents stale API responses from living in storage indefinitely. Next up we explore camera access with expo-camera.