Skip to content

Optionless endpoints still require 2nd param #1127

Closed
@drwpow

Description

@drwpow

For simple endpoints that don’t require any parameters or requestBodies, the 2nd param is still required:

import { paths } from './v1';

const { get } = createClient<paths>();
get('/self');
// ~~~~~~~~~~
// ^ Expected 2 parameters, but got 1.

The solution is adding an empty {} to the call, like so:

- get('/self');
+ get('/self', {});

This is because it’s an intersection of { params: … } & { body: … } & RequestInit, which are all required options, but in some scenarios end up having all keys optional which results in an empty object ({}). However, if we make the root types always optional, then the types break, and this library would be pointless.

If there’s a way to solve this without jeopardizing the types, PRs are welcome!

Though note that this is only a cosmetic issue. There are no actual performance or runtime bugs with providing an empty object as the 2nd param.

Counterpoint to fixing: Many APIs won’t have any endpoints with absolutely zero parameters. For the schemas that do, only a few endpoints realistically will deal with this. Further, simply having the 2nd param there can reduce Git diff noise if/when options are ever needed to be passed to that endpoint.

Metadata

Metadata

Assignees

No one assigned

    Labels

    PRs welcomePRs are welcome to solve this issue!bugSomething isn't workingopenapi-fetchRelevant to the openapi-fetch library

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions