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 navigation properties as currently declared on the request builder/api client directly. While this is convenient for discovery, it also means the whole graph structure gets pulled as soon as the client is used, which for such a large API means a long compilation time, negative impacts to auto completion etc...
Since those functions are "declared statically" (go idioms) we could move their declaration to the sub module they point to.
I.E. the declaration for users() on the service client would live under the users submodule and not on the root module.
What that means is that people would need an additional import (msgraphsdkgo/users) before they can use the navigation property, but it should greatly reduce build times since the compiler would only be pulling things the application needs to begin with.
We might run into circular dependencies while experimenting with that.
The text was updated successfully, but these errors were encountered:
I took some time to fiddle with that. Go doesn't support defining function receivers outside of the package where the type is defined.
What that means is we cannot have the "me" function defined in the "me" package instead of in the root one.
The alternative would be to have composed types defined at each package level. which would like to an experience like this one.
//medrive is an import of github.com/microsoftgraph/msgraph-sdk-go/me/driveresult, err:=medrive.Client(client).Get(context.Background(), nil)
iferr!=nil {
fmt.Printf("Error getting the drive: %v\n", err)
printOdataError(err)
}
fmt.Printf("Found Drive : %v\n", *result.GetId())
This completely breaks the fluent API design, which is a tradeoff decision we could make to drastically improve performance.
I haven't implemented this generation "style" yet because it represents a change in direction that needs to be discussed further.
The navigation properties as currently declared on the request builder/api client directly. While this is convenient for discovery, it also means the whole graph structure gets pulled as soon as the client is used, which for such a large API means a long compilation time, negative impacts to auto completion etc...
Since those functions are "declared statically" (go idioms) we could move their declaration to the sub module they point to.
I.E. the declaration for
users()
on the service client would live under theusers
submodule and not on the root module.What that means is that people would need an additional import (msgraphsdkgo/users) before they can use the navigation property, but it should greatly reduce build times since the compiler would only be pulling things the application needs to begin with.
We might run into circular dependencies while experimenting with that.
The text was updated successfully, but these errors were encountered: