Rewrite IndexedDB types to `[<ParamObject>]`?

[SimenLK]

Hey, pulled in the new changes to IndexedDB which changed some things up, but since I had been using a lot of dynamic typing in my original implementations, I tried using the newly added proper types.

Kinda annoying to work with interfaces, though the jsOptions isn't too bad:

let archives =
    db.createObjectStore("ArchivePolygons", jsOptions (fun o ->
        o.keyPath <- "ArchiveUuid"
    ))

Looking at paraobject, however, seems like the nicest option:

let archives =
    db.createObjectStore("ArchivePolygons", IDBCreateStoreOptions("ArchiveUuid"))

If we ignore the terrible interface names for IndexedDB, of course :) So from:

type [<AllowNullLiteral; Global>] IDBCreateStoreOptions =
    abstract keyPath: obj with get, set
    abstract autoIncrement: bool with get, set

to:

[<AllowNullLiteral; Global>]
type IDBCreateStoreOptions
    [<ParamObject; Emit($0)>]
    (
        keyPath: obj,
        ?autoIncrement: bool
    )
    =
    member val keyPath: obj = jsNative with get, set
    member val autoIncrement: bool = jsNative with get, set

@MangelMaxime, where do you stand on this? And @robitar, are you using IndexedDB, and would it break your applications?

[MangelMaxime]

And @robitar, are you using IndexedDB, and would it break your applications?

@SimenLK rewriting the library with [<ParamObject>] should be backward compatible as long as the names are kept consistent. At least, this was my conclusion when rewriting the Fable documentation.

Thanks to that, personally I am fine with the library being upgraded to [<ParamObject>]. I believe the only limitation with using [<ParamObject>] is that because you works with classes, you can compose/inherit as easily as with interfaces.

For this reason, I believe we should use [<ParamObject>] syntax only for objects that we build like options POJO and keep interfaces to represents exposed APIs like db.createObjectStore