You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The thing I don't fully understand, is why the types are separate from the microsoft graph client project, and why I need to explicitly typecast. It relies on me, the consumer, knowing the types ahead of time. I don't know the request or response data schema for all the endpoints, so how am I supposed to typecast? This approach seems a little risky to me, I could be typecasting wrong and could be using the wrong data structures.
Can someone clarify the situation and explain the microsoft graph client doesn't just use the types in this repo? It would make consumers's lives a lot better!
The client should provide the types for every endpoint. In the example below, as i consumer, I expect the client to tell me the types it expects:
// `user` should be typed by default// the return type should be typed by defaultclient.api(`/users/${id}`).patch(user);
If the types cannot be combined with the client, can i suggest a slightly better approach (imo) for handling types. Instead of typecasting we can use generics:
@badsyntax Thank you for your suggestion! The Microsoft Graph Client is the core library which is intended to be light weight with a set of specific functionalities. The typings library is intended to be an interface to the regularly updated metadata.
However, we do have plans to improve on the points you put forward in this issue.
Thanks for the reply @nikithauc Tbh I still don't fully understand why it's up to the consumer to provide the correct types. Perhaps another package is required? One that provides the correct types for msgraph-sdk-javascript, eg msgraph-sdk-typescript.
I agree with @badsyntax. As such this project seems almost completely useless to me, perhaps even actively worse then no types at all. Since the user has to typecast every request, you could write code like this (taken from the docs) and shoot yourself in the foot.
@nikithauc are there any alternatives to this library? Or am I missing something?
import{User}from'@microsoft/microsoft-graph-types';exportasyncfunctiongetUserAsync(): Promise<User>{return(client.api('/me')// Not requesting 'activities'.select(['displayName','userPrincipalName']).get());}asyncfunctiongetUserInfo(email: string){// Returns Users typeconstu=awaitgetUserAsync();// This will be null even though u is type as User which has the activities propertyconsole.log(u.activities);}
Hi there.
I've been using the microsoft graph client and the types in this repo.
The thing I don't fully understand, is why the types are separate from the microsoft graph client project, and why I need to explicitly typecast. It relies on me, the consumer, knowing the types ahead of time. I don't know the request or response data schema for all the endpoints, so how am I supposed to typecast? This approach seems a little risky to me, I could be typecasting wrong and could be using the wrong data structures.
Can someone clarify the situation and explain the microsoft graph client doesn't just use the types in this repo? It would make consumers's lives a lot better!
The client should provide the types for every endpoint. In the example below, as i consumer, I expect the client to tell me the types it expects:
If the types cannot be combined with the client, can i suggest a slightly better approach (imo) for handling types. Instead of typecasting we can use generics:
AB#8842
The text was updated successfully, but these errors were encountered: