[66696] Improve deserialization and object creation

[mrashed-dev]

This PR is a big one, it's aimed at two things -- improving how we deserialize objects while improving how users can create objects using the SDK.

Now, each Model type has an accompanying interface that represents an object of parameters that the Model will use, as well as the proper strictness dictated by what values will always be present in any scenario (GET, POST, PUT). In the constructor of each model, we now specify that we can take in an optional props property of the Model interface's type. This helps to hint the user as to what properties they must pass in during the initialization of the object. This also helps us with the strictness of the typing in each model as now we properly outline what properties are needed at a bare minimum.

This props method property is left as optional because it allows some flexibility to the SDK user to just instantiate a type of object then either:

• performing [model].fromJSON()
• or, setting the property values individually via [model].[property] = value
  If taking this route, we initialize all the required types to a default value in order not to upset Typescript's strictness requirements.

With this, we also deprecate the Nylas.[model].build() method as it provides a way for the user to bypass the constructor typing requirements and pass in whatever object they want. It also does not provide any type hinting to the user when trying to initialize the object, rendering this work useless. Here's an example of the before and after:

const Nylas = require('nylas');
Nylas.config({clientId: 'clientId', clientSecret: 'clientSecret'});
const nylas = Nylas.with('access_token');

// before, user can put whatever they want
const event = nylas.events.build({foo: "bar"});

// now, this way the user has to abide by EventProperties or else face a warning from Typescript

// throws warning:
const event = new Event(nylas, {foo: "bar"});

// does not throw warning
const event = new Event(nylas, {calendarId: "id", when: {startTime: 1234, endTime: 4321}});

// also does not throw warning, inits and object that has default values
const event = new Event(nylas);

License

I confirm that this contribution is made under the terms of the MIT license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[shortcut-integration]

This pull request has been linked to Clubhouse Story #66696: Improve Deserialization.

[mrashed-dev]

We can do it this way, or we can make CalendarProperties less strict allowing users to pass in as many or as little initial properties and basically do this.name = props?.name ? props.name : ""; for every required property. (This would be done to all similar models).

[mrashed-dev]

I added bang (!) as a modifier because we guarantee to set these values somehow -- either via the props that are sent in (which contain the strict properties) or if no props are sent in via setting default values.

[mrashed-dev]

Ignore merge conflicts for now please! The merge resolution will occur after #267 is merged. Jest is reporting all tests passing and linter + prettier was run on this project.

[philrenaud]

Good explanation; this is a nice change!

[ozsivanov]

Can we just initialize the props with '' instead of having this check?

[mrashed-dev]

Unfortunately, if we initialize props with anything other than an object of type IMAddressProperties (object with type and imAddress set) because of the strictness on those properties. The only way to do it like you're suggesting is to do something like constructor(props: IMAddressProperties = {type: '', imAddress: ''}) {

Alternatively, we can make all of these interfaces less strict allowing users to pass in as many or as little initial properties and in the do something like this.type = props?.type ? props.type : ""; for every required property.

[mrashed-dev]

I have re-worked the props to match what we talked about earlier. The properties now have default values without any extra checks.

[mrashed-dev]

The reason why all the classes have this initAttributes call instead of having it in the super class constructor (as it was earlier) is due to how TypeScript is designed in regards to how a child class is initialized. More info can be found here (thanks to @ozsivanov for finding this!): https://stackoverflow.com/questions/43595943/why-are-derived-class-property-values-not-seen-in-the-base-class-constructor