Skip to content
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

OpenAPI.ts Resolver typing is annoying, should use a Maybe type #2005

Open
ferretwithaberet opened this issue Jan 26, 2024 · 3 comments
Open

Comments

@ferretwithaberet
Copy link

ferretwithaberet commented Jan 26, 2024

Currently, the Resolver is defined as

type Resolver<T> = (options: ApiRequestOptions) => Promise<T>;

and keys like TOKEN are defined like:

export type OpenAPIConfig = {
  TOKEN?: string | Resolver<string> | undefined;
};

this is annoying in cases where you want to fetch the token from somewhere else, but it might be undefined as maybe it was not fetched yet or the user is not logged in.

Example

OpenAPI.TOKEN = () => {
  const user = getKeycloakUser();

  if (!user) return;

  return user.access_token;
};

I propose the following typing changes:

Resolver

type Maybe<T> = T | Promise<T>;
type Resolver<T> = (options: ApiRequestOptions) => Maybe<T>;

Keys like TOKEN

export type OpenAPIConfig = {
  TOKEN?: string | Resolver<string | undefined>;
};

Another note would be that, at the moment keys like TOKEN contain ? which marks them as optional, so | undefined is not required. I do not know if this is intentional as to make the typing more clear thought.

@sthenault
Copy link

I'm +1 on this, I've similar pb with building HEADERS where using a regular function is easier.

@mrlubos
Copy link
Collaborator

mrlubos commented May 6, 2024

@sthenault if you're interested in continuing this thread, please migrate to https://github.com/hey-api/openapi-ts and open an issue there

@sthenault
Copy link

noticed, thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants