Skip to content

[RFC] API for IndexedDB #68

Closed
Closed
@c410-f3r

Description

@c410-f3r

Summary

This RFC tries to establish an API for IndexedDB

Motivation

gloo doesn't have an API for IndexedDB, a fundamental technology for asynchronous persistent storage.

Detailed Explanation

Based on the discussions that took place in #3 and the now recently closed #59, I propose an "rust-ish" 1x1 implementation of the idb project that has a better alignment with the goals of the gloo team.

Two APIs are going to provided, a more complex and feature-complete IndexedDbFull and a simpler, quicker and easier IndexedDb that builds on top of IndexedDbFull. This way, the user has the option to choose whatever is best for his use-case.

IndexedDbFull and relatables

impl IndexedDbFull {
    pub fn delete_db(&self, name: &str) {}
    pub fn open(&mut self, database_name: &str, version: f64) -> IndexedDbFullVersionManager {}
    pub fn store(&self, name: &str) -> IndexedDbFullStorageManager;
}

impl IndexedDbFullStoreManager {
    pub fn all_keys(&self) {}
    pub fn clear(&self) { }
    pub fn delete(&self, key: &str) {}
    pub fn get(&self, key: &str) {}
    pub fn set(&self, key: &str, value: &str) {}
    pub fn transaction(&self, mode: &str) {}
}

impl IndexedDbFullVersionManager {
    pub fn upgrade(&self, cb: F) {}
    pub fn blocked(&self, cb: F) {}
    pub fn blocking(&self, cb: F) {}
}

let idb = IndexedDbFull::default();
let v = idb.open("foo-db", 1.0);
v.upgrade(|old, new, transaction| ... );
let s = idb.store("foo-store");
s.set("foo-key", "foo-value");

IndexedDb

Has a single hard-coded database, version and store.

// This is just a demonstration. `IndexedDb` and `IndexedDbFullStoreManager`
// are using the same trait definition for its methods.
impl IndexedDb {
    pub fn all_keys(&self) {}
    pub fn clear(&self) {}
    pub fn delete(&self, key: &str) {}
    pub fn get(&self, key: &str) {}
    pub fn set(&self, key: &str, value: &str) {}
}

let idb = IndexedDb::default();
s.set("foo-key", "foo-value");

The two APIs are using callbacks and their Future and Stream interfaces will have a very similar, if not equal, definition.

Drawbacks, Rationale, and Alternatives

The API focuses on simplicity but there are more complex projects like PouchDB and dexie.js.

Unresolved Questions

Should IndexedDbFullStoreManager, IndexedDbFullVersionManager and IndexedDb use the Fluent Interface pattern?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions