Skip to content

BUG: nullable schema #91

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

Closed
ssssota opened this issue Nov 14, 2022 · 6 comments · Fixed by #92
Closed

BUG: nullable schema #91

ssssota opened this issue Nov 14, 2022 · 6 comments · Fixed by #92
Labels
Type: Bug Something isn't working

Comments

@ssssota
Copy link

ssssota commented Nov 14, 2022

Hi! I think this project is useful and so interesting.

I have a question. Why do generator use interface for schema definition?

I think type alias is more useful.

e.g.

https://swagger.io/specification/#:~:text=A%20true%20value%20adds%20%22null%22%20to%20the%20allowed%20type%20specified%20by%20the%20type%20keyword%2C%20only%20if%20type%20is%20explicitly%20defined%20within%20the%20same%20Schema%20Object.

schema:
  type: object
  nullable: true
  properties:
    foo:
      type: integer
type schema = { foo: number } | null;
@Himenon
Copy link
Owner

Himenon commented Nov 15, 2022

It does not matter whether it is a Type Alias or an interface. I believe the essence of the issue is whether the problem is solved or not.

By the way, do you mean that there is a problem with specifying nullable in the case that @ssssota wrote about? Could you please provide some more details?

@Himenon
Copy link
Owner

Himenon commented Nov 15, 2022

When defined in components/schemas, nullable will not work, but will work elsewhere. It would be difficult to define a nullable schema in components/schema, but you want to use it here? In that case, it would probably be more convenient to use oneOf, but is it a situation where the schema cannot be changed?

openapi: 3.0.3
info:
  version: 1.0.0

components:
  schemas:
    Author:
      type: object
      nullable: true # Not works
      properties:
        name:
          type: string
    NullableAuthor:
      oneOf:
        - $ref: "#/components/schemas/Author"
        - type: "null"
  responses:
    Books:
      description: Get Books
      content:
        application/json:
          schema:
            type: object
            nullable: true # This works
            properties:
              author:
                type: object
                nullable: true # This works
                properties:
                  name:
                    type: string
              authorRef:
                $ref: "#/components/schemas/Author"
              author2:
                oneOf:
                  - $ref: "#/components/schemas/Author"
                  - type: "null"
              nullableAuthorRef:
                $ref: "#/components/schemas/NullableAuthor"

paths:
  /get/books:
    get:
      operationId: getBooks
      responses:
        200:
          $ref: "#/components/responses/Books"

You can check the operation in Playground (https://openapi-typescript-code-generator.netlify.app/v0.19.1/index.html).

@Himenon
Copy link
Owner

Himenon commented Nov 15, 2022

And this is not what we talk about in the topic of Type Alias or Interface. What you really want to do with the issue is to put it in the title. Otherwise, I will close this issue.

@ssssota

@ssssota
Copy link
Author

ssssota commented Nov 15, 2022

I believe the essence of the issue is whether the problem is solved or not.

I think so too.


I'm using OpenAPITools/openapi-generator to generate types and client. And I am considering where to migrate to.

I have schemas like follows:

components:
  schemas:
    member:
      type: object
      additionalProperties: false
      required:
        - child
      properties:
        child:
          $ref: "#/components/schemas/child"
    child:
      type: object
      nullable: true
      additionalProperties: false
      required:
        - name
      properties:
        name:
          type: string

https://github.com/ssssota/openapi-typescript-code-generator/blob/e1b63b408604def8686187698316eead3f8f5d1b/test/nullable.schema.domain/index.yml#L18-L36

This generator generates like follows:

    export interface member {
        child: Schemas.child;
    }
    export interface child {
        name: string;
    }

https://github.com/ssssota/openapi-typescript-code-generator/blob/6b3e5f573102dfcd9f0ffed4582f56df7719756f/test/__tests__/__snapshots__/nullable-schema-domain-test.ts.snap#L13-L18

I think it is not correct.
So, I patched with type-alias and generate like follows:

    export type member = {
        child: Schemas.child;
    };
    export type child = {
        name: string;
    } | null;

https://github.com/ssssota/openapi-typescript-code-generator/blob/e1b63b408604def8686187698316eead3f8f5d1b/test/__tests__/__snapshots__/nullable-schema-domain-test.ts.snap#L14-L19

This is why I asked the previous question.

And this is not what we talk about in the topic of Type Alias or Interface. What you really want to do with the issue is to put it in the title. Otherwise, I will close this issue.

OK. I'll change title.

@ssssota ssssota changed the title Question: Why generator use interface for schema definition? BUG: nullable schema Nov 15, 2022
@ssssota
Copy link
Author

ssssota commented Nov 15, 2022

is it a situation where the schema cannot be changed?

Maybe no.
However, I don't want to take that workaround.

@Himenon
Copy link
Owner

Himenon commented Nov 15, 2022

I published v0.19.2. Thanks your bug report !

And, I could align everything to type alias, but that would be a disruptive change to existing users and I need to provide options to minimize that. However, I do not have the time to provide that option, so I will only release a patch to allow nullable.

@ssssota

@Himenon Himenon added the Type: Bug Something isn't working label Nov 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants