teobler / swr-request-generator

A tool for generating TypeScript code and interface from swagger by using SWR and axios as client.

👋 Hi there

I'm Teobler, thank you for your attention.

You can ask me everything about agile and front-end.

📕 Latest Blog Posts

• To Be An Excellent Tech Lead
• To Be An Excellent Tech Lead
• Edge Function
• Re Thinking Architecture Of React Project
• The Fourth Anniversary

Feel free to reach me:

• 📫 Gmail: [email protected]
• 💬 WeChat Official Accounts: Teobler
• 🔭 Blog: Teobler

swr-request-generator's Issues

Example does not demonstrate use

I'd like to quote the READEME.md

how to use this file can be found in src/APP.tsx.

The use of the library/file is non-obviously included. At least, it is not in any of the dependencies of the file:

// https://raw.githubusercontent.com/teobler/swr-request-generator/main/example/src/App.tsx
import React from 'react';
import logo from './logo.svg';
import './App.css';

function App() {

The description implies one the following generated files is imported in the example project, but the current code does not include this.

• example/src/request/api.ts
• example/src/request/client.ts
• example/src/request/useGetRequest.ts
• example/src/request/useMutationRequest.ts

I would expect the example to demonstrate the use of the generated files.

Does this library support disabling of automatic revalidation

If I disable the revalidateIfStale option then SWR does not seem to make the initial request and therefore no data is rendered/retrieved

Is this a known issue? Any advice would be appreciated.

[BUG] Reusable enums cause error

When defining an enum within the components/schemas section of the openapi schema, it results in a crash. One would do this as to reuse the enum or simply return an array of enum values inside a property. The reason for this crash is the following:

Given is the following schema:

openapi: 3.0.3
components:
  schemas:
    Example:
      type: object
      properties:
        nestedEnum:
          type: string
          enum:
            - A
            - B
            - C
    Fruit:
      type: string
      enum:
        - Apple
        - Orange
        - Pear

We have a nestedEnum which is defined within an additional schema, while the Fruit enum itself is a top-level schema. This will produce the following resolved definitions:

{
  'ExampleNestedEnum#EnumTypeSuffix': [ 'A', 'B', 'C' ],
  Example: { 'nestedEnum?': 'ExampleNestedEnum#EnumTypeSuffix' },
  'FruitFruit#EnumTypeSuffix': [ 'Apple', 'Orange', 'Pear' ],
  Fruit: 'FruitFruit#EnumTypeSuffix'
}

The problem here, I believe, is that Fruit is a schema and as such causes not only the FruitFruit#EnumTypeSuffix to be created, but also itself gets inserted as a regular schema into the resolved definitions. This is done by the DefinitionsResolver regardless of the type of schema. This later on causes an error when the resolver fails to do so. In addition to this, there seems to be a naming issue in this circumstance, as seen by the name FruitFruit#EnumTypeSuffix which results in an enum named FruitFruit.

I have formulated my proposed changes in a PR #8

Not everything is generated when using multiple endpoints

Hi,

Our backend generates two openapi.json files that we need to generate all the hooks necessary. When adding both of these to the clients array property only the data from the first json file gets converted to generated hooks, the data from the second file is nowhere to be found. If I use just one endpoint in the clients field I can generate it for both seperatly.

If anything is unclear please let me know. Thank you!

Generator cannot (?) handle wrapped data from API

Sometimes, API data is wrapped in an object, e.g. data, because errors and meta information would be on the same level. The Open API schema could look like this:

  '/user/profile-information':
    get:
      tags:
        - user
      summary: Returns information about the current authentication status and user
      operationId: userProfileInformation
      responses:
        '200':
          description: 'Success'
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: array
                    items:
                      $ref: '#/components/schemas/AuthenticationData'

And the AuthenticationData schema could look like this:

    AuthenticationData:
      type: object
      properties:
        csrfToken:
          type: string
        user:
          $ref: '#/components/schemas/User'
        ssoUrl:
          type: string
        impersonationDetails:
          $ref: '#/components/schemas/ImpersonationDetails'
      required:
        - csrfToken
        - user
        - ssoUrl
        - impersonationDetails

(etc.)

This is valid OpenAPI configuration, however the generator cannot handle this and will fail to generate the interfaces.

How could this be implemented in the package?

Add support for yaml

Would be really useful to supporto also yaml files for openapi specification, other than json

Notify error for missing OperationId

If in the OpenApi endpoint the operationId is missing, the related hook is called with the generic name "useRequest".
So, if multiple endpoints don't have an operationId, the result is corrupted because is trying to export multiple functions with the same name.
An error indicating the problem would be useful to understand what underlying problem is causing the error

Remove useless prefix 'I' for interface in source code

[Proposal] remove rollup

this lib is just a script run in cli or npm script, rollup is too heave to this lib, using tsc is sufficient for our needs

[Feature request] Add support for the "default" response type

I'm currently generating an OpenAPI specification with the help of Apache CXF OpenAPI. This returns by default the following response object:

"responses" : {
          "default" : {
            "description" : "default response",
            "content" : {
              "application/json; charset=UTF-8" : {
                "schema" : {
                  "$ref" : "#/components/schemas/MyCustomDTO"
                }
              }
            }
          }
        }

I noticed that the generator only looks for the "200" response type, would it be possible to also add the "default" response type as a return type?

And another thing I noticed, is that the content./ wildcard is not working, I'm currently using a "application/json; charset=UTF-8" content type due to some special characters, but the wildcard is not catching this content type AFAIK.

[Proposal] remove useless prefix 'I' for interface

This change will be a breaking change, all interface reference will be broke.

[Feature request] Make use of summary/description fields in OpenAPI spec to provide comments.

Hi, First of all, thanks for writing this plugin.

I'm currently working in a multi-disciplinary team of front- and backenders, and it would be really useful if the generator also generates comments in the Typescript result (both for the types and the endpoints). The OpenAPI specification supports this with the help of "summary" and "description" fields.

AxiosResponse Inside AxiosResponse

This is maybe an error on my side.
But for some reason the result type of trigger is an AxiosResponse inside an AxiosResponse.

export function UserAuthForm({ className, ...props }: UserAuthFormProps) {
    const { trigger, isMutating } = useLoginForAccessTokenAuthPostRequest();
 
    const form = useForm<z.infer<typeof formSchema>>({
        resolver: zodResolver(formSchema),
        defaultValues: {
            username: "",
            password: "",
        },
    });

    async function onSubmit(values: z.infer<typeof formSchema>) {
        try {
            // According to the types this is a AxiosResponse<AxiosResponse<Token, any>, any> | undefined
            // But it is actually a AxiosResponse<Token, any> | undefined
            const result = await trigger({ body: { username: values.username, password: values.password } });

            if (!result) {
                throw new Error("No response");
            }
            console.dir(result);
            console.dir(result.data);
            // This does not work because the types are wrong
            const { access_token } = result.data.data;

This is my openAPI.json if you want to try
openAPI.txt

Dependencies should be added automatically

The files imported as dependencies (useGetRequest, useGetMutation) should be created automatically by the library during the generation process

[Question] Example or guidance to modify headers with mutations?

Hi, thank you for this library! It's mostly working great for me so far in a Next.js project.

I'm looking to move some WIP code to v1, as it has some bug fixes we need and improvements that look really good.

My question is how best to deal with the move of mutations to hooks, given that our use case requires a custom and varying auth header (a captcha token which expires after 2 mins).

Before, we could pass in a custom Axios right before making a call. I'm struggling to work out how to do that "late" / right before the call with the new version because React hooks can't be called in a callback fn where I was invoking the request before – only at the top level of the functional component.

Do you have any ideas? If it should be simple, do you think it would be possible to add an example that includes something like this?

[Bug] Snake case query parameters are incorrectly camelCase'd in `use*Request()` params

I see a similar issue was fixed in v1.0.0 and this resolved a bug we were seeing.

However I've just stumbled on a similar one in v1.2.1 when a query param is snake_case. This one seems to actually break the TS compilation rather than only leading to misleading interface signatures.

A snippet of input JSON which leads to the problem (inside a request's parameters list):

                    {
                        "name": "location_id",
                        "in": "query",
                        "required": false,
                        "schema": {
                            "type": "integer"
                        }
                    },

And here's what we get: