-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved Organisation of APIs #7
Comments
Thanks for the feedback @KaiTheRedNinja! Great idea! I 100% agree it would be great to be able to better organize large API groups. Unfortunately macros are relatively nascent and so there are a few limitations:
Ideally, I think it would be great to completely hide the implementor of the protocol. This way there wouldn't be a bunch of concrete API types floating around and calling the API would look something like this: @API
protocol GRAliases { ... }
let aliases: GRAliases = provider.create(GRAliases.self)
let result = try await aliases.listAliases(...) Macros generating extensions would also unlock the |
With SE-404 organizing APIs inside a type is possible now... public enum APIs {
@API
public protocol Foo {
@GET("/bar")
func bar() async throws
}
}
let foo: APIs.Foo = APIs.FooAPI(provider: provider) Unfortunately there's still no way for macros to extend types that they aren't annotating - but I think with this answer you should be able to get more organized outputs as long as there's a consistent suffix. |
Issue:
When it comes to larger APIs, for example, the Google Classroom API, which I work with very often at glassroom, using Papyrus would result in a lot of messy top-level APIs.
How glassroom currently solves this is to declare all the protocols as enums, and all the functionality goes into extensions of those enums as static functions. This means that the definitions look like this:
and calling functions looks more like this:
However, since Papyrus uses protocols for the definitions and the resultant APIs are autogenerated, such organisation cannot be achieved.
Suggested solution:
My suggestion is to have an option in
@API
and@Mock
to extend a struct with the new functionality, instead of generating a whole new struct. This would allow for organisation by defining all the structs in a neat manner.And you would call them this way:
The text was updated successfully, but these errors were encountered: