พื้นที่จัดเก็บในเครื่องและ IndexedDB

When building desktop applications with Electron, you often need to save user data or application settings. This is called data persistence.

Unlike web apps that rely on servers, Electron apps can store data directly on the user's computer. This lesson explores two common browser-like storage methods: localStorage and IndexedDB.

Electron's renderer processes are essentially web browsers. This means you can use standard browser APIs for data storage, like the Web Storage API.

The Web Storage API provides two main types:

• localStorage: Stores data with no expiration date.
• sessionStorage: Stores data only for the duration of the browser session.

We'll focus on localStorage for persistent data.

localStorage allows you to store data as simple key-value pairs. Think of it like a small, local dictionary.

• Persistence: Data stored in localStorage remains even after the app is closed and reopened.
• Scope: Data is unique to the origin (your app's domain, usually file:// for Electron).
• Capacity: Limited to about 5-10 MB per origin.

It's great for small amounts of data like user preferences or simple settings.

You can store data in localStorage using the setItem() method. Remember, values are always stored as strings.

Try running this example in your renderer process:

To get data back, use getItem(). To delete, use removeItem(). If you stored an object, you'll need to parse it back from JSON.

Run this snippet after the previous one:

While easy to use, localStorage has some limitations:

• Size Limit: Typically 5-10 MB per origin. Not suitable for large datasets.
• String-Only: All data is stored as strings. Objects and arrays must be manually serialized (e.g., with JSON.stringify()) and deserialized (JSON.parse()).
• Synchronous: Operations block the main thread, which can cause UI freezes if you're storing/retrieving a lot of data.
• No Indexing/Querying: You can't directly query data, only access by key.

For larger, more structured, and complex data, IndexedDB is a powerful alternative. It's a low-level API for client-side storage of significant amounts of structured data.

• No Size Limit: Generally limited only by available disk space.
• Structured Data: Can store JavaScript objects directly, not just strings.
• Asynchronous: Operations don't block the UI thread, making it suitable for performance-critical apps.

IndexedDB works with a few key concepts:

• Databases: You create databases, each with a name and version.
• Object Stores: Like tables in a relational database, but they store JavaScript objects. Each object store has a key path.
• Indexes: For fast querying of data within an object store.
• Transactions: All read and write operations must occur within a transaction, ensuring data integrity.
• Asynchronous: Operations return IDBRequest objects, which resolve with success or error events (or Promises).

Setting up IndexedDB involves opening a database and defining object stores. This is usually done in the renderer process.

This example shows how to open a database and create an object store if it doesn't exist:

Great job! You've explored client-side data persistence in Electron:

• localStorage is simple, synchronous, key-value storage for small, non-critical data.
• IndexedDB is a powerful, asynchronous, transactional database for large amounts of structured data.

Choosing between them depends on your data's size, structure, and performance needs. Both are crucial for building robust Electron applications that save user data locally.