Prompt
Use expo-file-system to write a text file to the document directory, then read it back and display the contents.
Solution
The file system is the storage tier for things that are files — images, PDFs, exported data, downloaded media — where AsyncStorage's string KV and SQLite's rows are the wrong shape. The API here is simple; the knowledge being tested is the directory contract.
FileSystem.documentDirectory is the app's persistent, sandboxed home: files survive restarts and OS cleanup, and it's included in device backups. Its sibling cacheDirectory is the opposite deal — the OS may evict it under storage pressure, which makes it the right home for re-downloadable content and the wrong home for anything the user created. Choosing between them is the design decision; everything else is plumbing. The critical discipline: these are URIs you get at runtime, and the sandbox's absolute path can change between installs and app updates (notoriously on iOS) — so you persist relative filenames and re-derive the full URI from documentDirectory on every launch, never store absolute paths.
Pattern notes on the code: an async function declared-then-called inside useEffect (the effect callback itself can't be async — it would return a promise where React expects a cleanup); string reads/writes default to UTF-8, with base64 encoding as the option for binary payloads. Real code adds try/catch — disk-full and missing-file are ordinary runtime events, not exceptional ones.
Red flag: persisting an absolute file path and reading it after an app update — the container moved and your "saved" file is gone. Store names, derive URIs.
Say it: "documentDirectory is persistent and backed up, cacheDirectory is evictable — and since the sandbox path can change across updates, I persist relative filenames and rebuild URIs at runtime."