apple / swift-openapi-generator

Generate Swift client and server code from an OpenAPI document.
https://swiftpackageindex.com/apple/swift-openapi-generator/documentation
Apache License 2.0
1.23k stars 89 forks source link

Add ability to attach protocols to generated models #573

Open armintelker opened 2 weeks ago

armintelker commented 2 weeks ago

Motivation

We need all of our models generated by swift-openapi-generator to comply with protocols like Equatableor Identifiable to work with our overlaying architecture. Manually extending each generated model to conform to these protocols is insufficient and cumbersome, especially as the number of models increases.

Proposed solution

Add a feature to the swift-openapi-generator that allows specifying which protocols the generated models should conform to. This could be implemented as a configuration option in the generator, enabling automated protocol conformance during the model generation process.

Alternatives considered

The current workaround is manually extending each generated model, like so:

extension ModelA: Equatable {}
extension ModelB: Equatable {}
extension ModelC: Equatable {}
extension ModelD: Equatable, Identifyable {
    var id: Int 
    //...
}

However, this approach is not scalable and becomes unwieldy as the number of models grows.

Additional information

If there is already an existing feature to achieve this, i apologize for the oversight and kindly request guidance to the relevant documentation. I could not find any reference to such a feature in the current documentation.

References:

Identifiable Documentation Equatable Documentation Thank you for considering this request.

czechboy0 commented 2 weeks ago

Hi @armintelker,

all generated types already conform to Equatable, as we generate the Hashable conformance (which includes Equatable).

Identifiable, on the other hand, is tricky, as it's not clear what the id property should return for arbitrary schemas. What would be your expectation?

armintelker commented 2 weeks ago

Hey, thanks for the quick response. I have overseen that the DTO is already conforming to Hashable. This makes, of course, everything a lot easier. So my request gets kind of needless. Indeed the Identifiable protocol suggestion would be more like a "nice to have". I could imagine that the generator could add the Identifiable to the model as soon it sees a property id exists that also conforms to the constraint of the protocol.

czechboy0 commented 2 weeks ago

I could imagine that the generator could add the Identifiable to the model as soon it sees a property id exists that also conforms to the constraint of the protocol.

In theory yes, but my first instinct is that this would be considered out of scope of an OpenAPI generator. I think a separate build plugin that processes your Swift code and adds Identifiable to any struct that has an id property would be more appropriate, and more maintainable. This is a feature that would be useful outside of the OpenAPI context.

simonjbeaumont commented 1 week ago

This is similar to #383, where could conceivably attach arbitrary conformances or macros that are stated in the config file and it be up to the adopter to ensure these are available in their project.

It wouldn't be too different from the ability we have know to express additionalImports.

czechboy0 commented 1 week ago

That's true, @simonjbeaumont, and the macro itself would contain the logic for how to e.g. implement Identifiable, instead of the generator having to know how to do it. I like that.