Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite IndexedDB types to [<ParamObject>]? #126

Open
SimenLK opened this issue Nov 9, 2023 · 1 comment
Open

Rewrite IndexedDB types to [<ParamObject>]? #126

SimenLK opened this issue Nov 9, 2023 · 1 comment

Comments

@SimenLK
Copy link

SimenLK commented Nov 9, 2023

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
Copy link
Member

MangelMaxime commented Nov 9, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants