[Typescript] Fix oneOf

[ksvirkou-hubspot]

#9305

Doesn’t work "oneOf"

"items":{
   "oneOf":[
      {
         "$ref":"#/components/schemas/SingleFieldDependency"
      },
      {
         "$ref":"#/components/schemas/ConditionalSingleFieldDependency"
      }
   ]
}

import { OneOfSingleFieldDependencyConditionalSingleFieldDependency } from './OneOfSingleFieldDependencyConditionalSingleFieldDependency';

...

'inputFieldDependencies'?: Array<OneOfSingleFieldDependencyConditionalSingleFieldDependency>;

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master, 5.1.x, 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[ksvirkou-hubspot]

@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov

[ksvirkou-hubspot]

Any updates on this?
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov

[amakhrov]

Thanks for your contribution! The fix looks good to me - as far as I can see what it does.
Could you please add unit tests, both to demonstrate the fix working and to prevent regressions in future?

And if you even feel like going an extra mile here - it would be super beneficial (and highly appreciated! :) ) to add a sample with oneOf/allOf (looks like no existing typescript samples use a spec with this feature - #5335)

[amakhrov]

why do we need this?

[ksvirkou-hubspot]

Thanks for your contribution! The fix looks good to me - as far as I can see what it does.
Could you please add unit tests, both to demonstrate the fix working and to prevent regressions in future?

And if you even feel like going an extra mile here - it would be super beneficial (and highly appreciated! :) ) to add a sample with oneOf/allOf (looks like no existing typescript samples use a spec with this feature - #5335)

Hi
there is only oneOf but after this fix It would be much easy to add allOf
I don’t know about unit tests but I'll try to look

[ksvirkou-hubspot]

I added
typeMapping.put("map", "any");
because I saw it in codegen
import { ModelMap } from './ModelMap';
it was adding to every model
I researched how it was fixed at typescript-node
and done the same

[ksvirkou-hubspot]

openapi-generator/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractTypeScriptClientCodegen.java

Lines 163 to 164 in 46f8a67

	typeMapping.put("Map", "any");
	typeMapping.put("map", "any");

[ksvirkou-hubspot]

@amakhrov ^^

[ksvirkou-hubspot]

Hi
I 've just committed unit tests
@amakhrov @macjohnny

[TiFu]

I have spent some time thinking about how to "properly" implement oneOf/anyOf/allOf in the context of the generator.

I believe the current solution is not sufficient, due to 2 reasons

• Implementing anyOf with a union type is incorrect, see the below example which to my understanding would emit AnyOfPet = PetByAge | PetByType instead of allowing AnyOfPet = PetByAge | PetByType | (PetByAge & PetByType)
• ObjectSerializer is not able to correctly serialize/deserialize is not able to properly deserialize/serialize union types (as far as I am aware) - i.e., something like "Array<A | B | C>" will not be correctly parsed (currently: No further serialization/deserialization is done)

Fixing this will be quite a bit of effort, as we need to

• [Easy] Make ObjectSerializer "understand" union types (both |, &)
• Add an algorithm to properly check anyOf (i.e., it can be A & B & C, or A&B or A&C but not A & (half of) B. One approach could be a) For an object o, check for all types t in anyOfTypes, whether o has all (required) properties of t. Then, check whether all properties in o are covered by the t's that matched o, and that there are no conflicts

        AnyOfPet:
          anyOf:
            - $ref: '#/components/schemas/PetByAge'
            - $ref: '#/components/schemas/PetByType'

        PetByAge:
          type: object
          properties: 
            age: 
              type: integer
            nickname: 
              type: string
          required:
            - age              

        PetByType:
          type: object
          properties:
            pet_type:
              type: string
              enum: [Cat, Dog]
            hunts:
              type: boolean
          required: 
            - pet_type

as

[amakhrov]

Frankly, accurately representing anyOf or non-discriminated oneOf in TS (or in general, I guess) is so cumbersome that I feel like it's not worth efforts. For starters, you're doomed to use type assertions every time you work with such a combined type, since TS has no way to know which combination of A/B/C is matched in a particular instance of our (anyOf A/B/C). Or you have to generate a bunch of type guards (one for each of A, B, C)

Also for the purpose of (de)serialization, we don't have to be type strict. Whatever properties are present in the input, we deserialize then to a corresponding type, assuming there is no conflicting props between A/B/C. And it's a job for the validator to ensure no conflicts, not a job for the serializer. Imo :)

[ksvirkou-hubspot]

Hi @TiFu
I agree with @amakhrov
Can we merge it ?
it doesn’t work now
it would be great to merge it
Because for us it is blocker

[TiFu]

I agree with @amakhrov :-)

Both CI failures are unrelated (1 due to pull rate limit, 1 due to CSharp Generator Tests). Let me try if we can get at least that other one to work.

[TiFu]

Alright. Merging this :-). Thank you for the PR!

• Appveyor fails due to an issue in the csharp samples.
• Travis fails due to request limit