IndexedDB: structured data in the browser

Useful to know

The browser can store not only a single preference, but also larger structured data sets. IndexedDB is an interface for such work by the client. It allows for retrieval and modification through asynchronous operations and uses transactions. [1] This is the basis for, for example, a local catalog or notebook that needs to find individual records. However, the presence of a base in the browser does not mean that the storage task is now completely solved only with the choice of technology.

In IndexedDB, records are organized by keys, and values can be complex structured objects. Indices give additional paths to search by properties of these objects. [2] Thus, an application can view individual records instead of constantly converting its entire set into a single large text string. For the designer, the important question is what references will actually be needed. The layout should follow the usage, not just copy the appearance of a table from another kind of base.

The work begins with defining a scheme and opening a link. Read and write requests are then executed in transactions. The asynchronous approach allows the operation to be processed without the main interface necessarily waiting by means of a block call. [1] This does not eliminate the need for a state of "loading" and error handling. The user should get a clear answer when the data is ready, and not see a blank screen, which can mean both a lack of records and an unfinished operation.

The model is different from an ordinary imaginary file drawer. Changes are made in a transactional context, and access follows the page's origin restrictions. IndexedDB can support applications that work without a permanent network connection. [2] The mere fact that the record is locally available, however, does not say how and when it was sent to a server. The local state and the state in the remote system are two separate things that the application must consciously reconcile.

Consider a note created during a trip without the Internet. It can be saved locally and displayed again the next time the app is opened. When the link is returned, new questions arise: whether the note was sent, what happens on retry, and whether there is a change from another device. This is an example of a synchronization logic that is not automatically derived from the presence of IndexedDB. A clear distinction is needed between "reserved here" and "synchronized."

Browsers have their own rules for available space and managing local data. [1] Important information should therefore not receive a promise of unconditional permanent storage based on the local record alone. When designing, a missing base, a change of scheme and a failure of operation are checked. The well-used IndexedDB provides richer capabilities for a fast and sustainable interface when these capabilities are part of a thought-out data lifecycle, rather than a substitute for all other care for them.