Invalid Typescript schema requested for POST

[bnhovde]

Hi, love this initiative. It's allowed me to remove hundreds of lines of code.

I've got a strange problem trying to wire up a POST request using the standard approach:

export const submitForm = fetcher.path('/form/{formId}/submit').method('post').create();

The Swagger API definition requests formId as a parameter and formFields as the post body, but the returned function requests the following input, a intersection between an object and an array, which is impossible to provide:

I might be doing something wrong, but it seems like a potential bug. Here's the type for the request:

"/form/{formId}/submit": {
    post: {
      parameters: {
        path: {
          formId: string;
        };
      };
      responses: {
        /** Success */
        200: {
          content: {
            "text/plain": components["schemas"]["FormModel"];
            "application/json": components["schemas"]["FormModel"];
            "text/json": components["schemas"]["FormModel"];
          };
        };
      };
      requestBody: {
        content: {
          "application/json":
            | components["schemas"]["FormFieldInputModel"][]
            | null;
          "text/json": components["schemas"]["FormFieldInputModel"][] | null;
          "application/*+json":
            | components["schemas"]["FormFieldInputModel"][]
            | null;
        };
      };
    };
  };

[ajaishankar]

Thanks @bnhovde

It is definitely a bug, wasn't anticipating body to be a top level array...

Will fix in next version - thinking for this special case the arg would be typed as

type Arg = {
  formId: string
   __body: {
    identifier: string
    value?: number | null | undefined
    observedAt?: string | null | undefined
  }[]
}

[ajaishankar]

@bnhovde as a workaround you could try

submitForm(
  Object.assign(
    [ { identifier: "id", value: 1, observedAt: "now" } ], // body array first
    { formId: "form1" } // param next
  )
)

You still get type safety on the required properties.

[bnhovde]

@ajaishankar That makes sense! Thanks for the workaround.

I suppose it's a bit of an edge case. It feels intuitive to pass the POST/PUT-body as the second argument of a fetcher, e.g submitForm({ formId }, data);, but I appreciate that might not fit in.

Amazing work, I found no other hiccups implementing this.

[ajaishankar]

Thanks @bnhovde!

Glad to know it works well on real world schemas. Closing this issue for now since there is a workaround. Will reopen if more users have schemas with similar array based request bodies.

[kirypto]

Hate to say it, but I think I might have evidence that top level arrays in a body is a fairly common usecase: RFC 6902 - Section 3.

That being said, it does look like the workaround and the utility function arrayRequestBody you provided is doing the trick! Just made use of it, and as with the rest of the library, it trivialized the problem. Really glad I ran across this library.
Honestly this is the first time I've had an API service actually backed directly by the openapi spec with type validation and it's fantastic.