IndexedDB

[Joe-Jones]

I have started working on bindings for IndexedDB. If no one else is working on this I'll keep going.

The IDL has quite a few event handlers like the ones that follow

attribute EventHandler onsuccess;
attribute EventHandler onerror;

should I ignore these in favor of adding event handlers via add_event_listener.

[koute]

I have started working on bindings for IndexedDB. If no one else is working on this I'll keep going.

That's great; thanks!

should I ignore these in favor of adding event handlers via add_event_listener

Yes.

[Joe-Jones]

The Indexed DB API has quite a lot of methods with optional arguments, I was wondering how these should be translated. For instance the open method of the IDBFactory interface has an optional second argument. I could either split this into two methods

let open_db_request = indexed_db.open("db_name");
let open_db_request = indexed_db.open_with_version("db_name", 2);

or I could make a method that can take either an integer or None, or an Option.

let open_db_request = indexed_db.open("db_name", None);
let open_db_request = indexed_db.open("db_name", 2);

The method signature that does that is a bit complicated but as long as I put examples in the documentation I think that's OK. The signature is

pub fn open<T: Into<Option<u32>>>( &self, name: &str, version: T) -> IDBOpenDBRequest 

Which of these should I prefer, or is there another way of doing this.

Another question is, there are several enums in the API. Javascript treats these as strings and I could simple pass them into rust as strings. With a bit more effort They could be converted to Rust enums and converted as they are passes back and forward to Javascript. Do you agree this is worth the effort.

[koute]

Which of these should I prefer, or is there another way of doing this.

Number (1) or (2) would be the most preferable. (1) looks more idiomatic and Rust-y, while (2) is a little closer to the original JS API. In this case I guess either one would be fine. (I can't really say "always use XXX" as we currently tend to use both approaches on a case-by-case basis.) However, the more optional arguments a method has, the more preferable is variant (1).

Another question is, there are several enums in the API. Javascript treats these as strings and I could simple pass them into rust as strings. With a bit more effort They could be converted to Rust enums and converted as they are passes back and forward to Javascript. Do you agree this is worth the effort.

That depends on a particular enum, but if it's an enum with strictly defined variants then yes! We want to use Rust's enums as much as possible instead of having stringly-typed APIs like in JavaScript.

[anlumo]

What is the current state of this feature?

[Joe-Jones]

Hi,

substantially complete. I shall submit a merge request soon.

I haven't been working on this much recently, just making sure I've merged changes from master and that it compiles.

I think I've wrapped all the object types in the API, I have also added documentation to all the method calls. No tests I'm afraid. There maybe be some question about how a few of the methods have been wrapped. I have tidied the code up and the only warnings are from other parts of stdweb.

I have also created an demo in the examples directory, it has been translated from one of the MDN examples.

It would probably benefit from using futures, I haven't looked at that yet.

[Pauan]

@Joe-Jones Futures are easy to work with in stdweb, but I think they'll be a bit tricky to integrate with IndexedDB (simply because IndexedDB's API is a bit... weird).

Here's an example of how to write a Future API in stdweb:

#[cfg(feature = "futures-support")]
use webcore::promise_future::PromiseFuture;

impl IDBRequest {
    #[cfg(feature = "futures-support")]
    fn wait( &self ) -> PromiseFuture< () > {
        js!(
            var self = @{self};

            return new Promise( function ( resolve, reject ) {
                self.addEventListener( "success", function () {
                    resolve( undefined );
                }, true );

                self.addEventListener( "error", function () {
                    reject( self.error );
                }, true );
            } );
        ).try_into().unwrap()
    }
}

It uses #[cfg(feature = "futures-support")] to ensure that the future API only exists if the futures-support flag is turned on. It needs it on both the PromiseFuture import and also the method definition.

For the method itself, it just needs to return PromiseFuture< Value >, where Value is the output type of the Promise. Value can be anything which can be serialized by stdweb: String, Vec, various numbers, etc. In this particular case the Promise outputs undefined, so it uses () for the type.

Then you just use js!( return ...; ).try_into().unwrap() as usual. Make sure that the JS code returns a Promise.

After that it's just normal JS code which wraps the IndexedDB operation in a Promise.

---

As an example of how the above future API would be used:

let transaction = db.transaction(&["foo"], TransactionMode::ReadWrite);

let store = transaction.object_store("foo");

await!(store.add(5).wait())?;

Note how it calls .wait() (which returns a Future), and then await!s it.

[svenstaro]

Wanna make that PR soon so that we can comment on it?

[Joe-Jones]

I just got round to submitting a merge request #297

I won't get a chance to look at this over the next couple of weeks. After that I'm going to make some time to work on it.