Implement all data model classes, with methods that wrap the REST api

[paperdave]

the structure/"data model" classes are things like Interaction, and all of them primarily function by wrapping a raw data object passed to the constructor then accessor methods for every property, converting sub objects into more rich types & adding methods that wrap the rest api. these structures are mostly immutable.

one system I have to get better typed classes for things such as a partial channel (where you only have a string id), I have a typescript type that casts a class to an empty looking one, where supported properties and methods are available. for example, the PartialUser class does not have banner data but it does have a name and discriminator, and the fetch method will fetch the full user object.

before we go and blindly implement everything under this system, it might be worth a lot to consider a different approach to creating all these rich data models (I now really like that name name, "rich data models"). this might involve a mini library that assists in creating classes that wrap a data object, where each computed property defines a list of dependencies, and then with typescript types we can create an infinite amount of partials in any shape we need, with an interface like PartialModel<User, "id">, where id refers to the raw data, generating a class definition that only shows properties and methods that would be safe to call. under this system and the current one, the actual class object that js runs would always be the same.

I dont have a code example of what the library would look like, but it should be easy to add new properties to models, and hopefully not perform too slowly compared to just writing a plain class (maybe run faster if we allow computed props to be cached, maybe not).

• decide if we want a different system for defining rich models
• TODO, insert a checklist of every class we need. and all rest methods.

[paperdave]

For the record, #7 must be merged before we continue dev on the data models

[paperdave]

While i love the naming of model, it might be better to call it structures as

• other libs call it that
• discord api library does that too

unless we wanted to split the utilities for creating structures into a model package, but unsure if that has a lot of true merit