MLIBZ-2314 Updated typescript definitions #242
Conversation
| @@ -544,6 +544,7 @@ interface RequestOptions { | |||
| properties?: Properties; | |||
| timeout?: number; | |||
| useDeltaFetch?: boolean; | |||
| version?: string; | |||
There was a problem hiding this comment.
This change should've been in my previous typescript PR #235 . I did not realize we had two copies of the ts definitions in the same file.
| @@ -436,8 +436,8 @@ export namespace Kinvey { | |||
| static loginWithMIC(redirectUri: string, authorizationGrant ? : AuthorizationGrant, options ? : RequestOptions): Promise < User > ; | |||
| logout(options ? : RequestOptions): Promise < void > ; | |||
| static logout(options ? : RequestOptions): Promise < void > ; | |||
| signup(data: {}, options ? : RequestOptions): Promise < this > ; | |||
| static signup(data: {}, options ? : RequestOptions): Promise < User > ; | |||
| signup(data ? : {}, options ? : RequestOptions): Promise < this > ; | |||
There was a problem hiding this comment.
Shouldn't the data type of all of these be "any"?
There was a problem hiding this comment.
I had to look this up. Turns out, there's a subtle difference - https://stackoverflow.com/questions/18961203/typescript-any-vs-object
Based on that article (see last note in this answer - https://stackoverflow.com/a/28795689), I feel using object is the most appropriate. Doesn't have to be in this PR, but {} is still better than any. We want to be as restrictive as possible, to avoid bad input. Thoughts?
There was a problem hiding this comment.
I guess when defining a method argument in a definition file, we can use object (or {} which seems to be the same) and it is better. Although it still allows you to pass a function.
But don't we know even more about this object? Like it should have a username and password properties, no?
There was a problem hiding this comment.
I think we do but it can also have much more then just these properties. Lets look at updating these definitions going forward but lets not hold up this change since currently it will throw and error if no data is provided.
There was a problem hiding this comment.
Sure, I wasn't requesting changes at any point.
But the way to define the data type is something like this:
interface UserData {
[key: string]: value: any
}
interface UserSignUpData extends UserData {
username: string,
password: string
}This way you have the two properties, but can add as many more as you like.
Description
Updated definition of
signup()to allow zero parameters (required to signup as implicit user)Changes
Minor change to
.tsfile.