Allow better types for DataReference and DataSnapshot

[futurGH]

DataSnapshot#val() always returns any, despite the fact that, given the existence of TypeMappings binding, a user will often know at compile time what type will be returned. I have a few suggestions for type-level changes with no runtime impact, apart from the 3rd option, listed roughly in order from least change to acebase-core to greatest internal change. I'd be happy to submit a PR for any of them, just wanted to get feedback first.

Option 1 (Generic-as-cast)

Workbench Example

const snapshot = await db.ref<MyClass>("foo/test").get();
const value = snapshot.val();
//    ^? - MyClass

• Simplest internal implementation, no runtime impact on JS
• Equivalent to snapshot.val() as MyClass
• Potentially controversial because it can hide the fact that there's no type checking going on, especially for developers new to AceBase and/or the codebase

Option 2 (User declaration merging)

Workbench Example

declare module "acebase" {
    interface BindingMap {
            "foo/*": MyClass;
    }
}
const snapshot = await db.ref("foo/test").get();
const value = snapshot.val();
//    ^? - MyClass

• Moderate option; allows users to declare mappings on the type level with the same syntax used for TypeMappings#bind
• Can default to any for users not using type mappings
• May be unintuitive depending on user's knowledge of TypeScript

Option 3 (bind as assertion function)

Workbench Example

db.bindType("foo/*", MyClass);
const snapshot = await db.ref("foo/test").get();
const value = snapshot.val();
//    ^? - MyClass

• "Just works" if user binds types with TypeMappings
• Unfortunately would require bind to be implemented as a top level method of AceBase, as current TypeScript limitations prevent the functionality used from working if it's nested in a member class
• Would be a breaking change for all users

[appy-one]

Thanks, that all looks great! I'll try out the code from the workbenches, great stuff!

[appy-one]

Sorry it's taking a while to get back to you, I've been working to port all last js bits of all acebase packages to typescript. I'm almost finished, so I'll take another look at this once everything is working well and published. Thanks again!

[futurGH]

No worries! Let me know what you think whenever you can find the time to take a look and I'd be happy to get to work on an implementation.

[Bubz43]

I've personally been using something similar to option 2 and it seems to work quite well.

Minimal Example Playground

Throw any object interface at it and you are good to go, though you are lying about the shape of the DB data and have to keep in mind you need some other way actually guarantee correctness on initial creation/migrations.

[futurGH]

Totally agree, thanks for the example! With compile-time–only type checking like TypeScript's, there's always the risk that data won't line up with expectations, especially when it's being moved across file system boundaries as in the case of a DB. I've been using a version of option 2 in my own projects as well, and it's definitely best accompanied by a runtime function to assert that the received type is indeed what you're expecting.

[futurGH]

Hope you don't mind a quick bump @appy-one — I haven't been using AceBase as of late so if there's interest I'd love to submit a PR while the implementation is somewhere in my brain 🙂

[appy-one]

@futurGH yes please, you are more than welcome to! I think option 1 would be the best starting point for now, maybe option 3 at a later stage!