JS client does not support polymorphic return types

[delenius]

In the generated constructFromObject functions, the descriminator property is ignored, which means that an instance of the abstract superclass is created. For example, if I have this in my swagger.yaml:

Vehicle:
  type: "object"
  required:
  - "vehicleType"
  discriminator: "vehicleType"
  properties:
    vehicleType:
      type: "string"

Car:
  allOf:
  - $ref: "#/definitions/Vehicle"
  - type: "object"
    required:
    - "vehicleType"
    properties:
      vehicleType:
        type: "string"

Bicycle:
  allOf:
  - $ref: "#/definitions/Vehicle"
  - type: "object"
    required:
    - "vehicleType"
    properties:
      vehicleType:
        type: "string"

then, according to my understanding of how it should work, if the vehicleType is "Car", then a new Car instance should be generated, and if vehicleType is "Bicycle", a new Bicycle instance should be generated.

Currently, all I get is a new Vehicle instance.

[delenius]

A workaround would be to have a mode where you don't generate these "models" at all -- just return the raw data. That would also make the client much smaller. With my rather large spec, I get a rather bloated client, and I don't really have any use for all these "model" classes...

[demonfiddler]

Agree regarding code-bloat from model classes if these don't actually contribute any useful functionality. Model-driven content assist (auto-complete) is useful functionality but it doesn't necessarily have to be driven from JavaScript - Tern.js, for example, has a 'condense' utility whose output is a JSON API definition from which the Tern server can generate completion proposals.

However, from a pure modelling perspective, potential functionality in the model classes could include dynamic enforcement of modelled:

• containment semantics (i.e., containment is intrinsic to JSON but unknown to JavaScript)
• cross-reference semantics (i.e., cross-references are unknown to JSON but intrinsic to JavaScript)
• min, max, length, enum and other constraints
• runtime type safety (i.e., set property accessor rejects invalid parameter)
• multiplicity bound constraints
• uniqueness within multi-valued (array) properties
• round-trip JSON serialisation and deserialisation

Some (but not all) of the above could alternatively be implemented in generated validator classes. But overall I agree that it would be a good idea to make model generation optional.

[skydiablo]

hmmm... any fixes ?

[triptec]

How would we like to solve this? @wing328 ping