Suggest to remove singleton OpenAPI object and make Clients instanced.

[cmcnicholas]

Currently the Client templates reference a single OpenAPI reference which is used to set the token or headers.

An example where this approach fails is trying to contact two API's with the same generated codegen, we frequently do this e.g. from staging to live environment stagingapi.product.com -> api.product.com and there isn't really a workaround other than set the token before every request.

This does lead on to the question as to why the client functions are templated as statics, I believe having to instance the clients and provide the configuration would work better with DI and testing frameworks.

[jacobe]

There are lots use cases where separate Service instances would come in handy. This would typically be when contacting different backend services or with different configurations. One example is having different kinds of credentials for different situations. There's currently no way of propagating the "context" in which the static Service methods are called.

As an example, we'd sometimes like to call an endpoint as the authenticated user and sometimes elevated to an "admin". We'll currently have to resort to something like:

OpenAPI.TOKEN = (options) => {
  const request = getCurrentRequest()  // A hacky way of getting the currently executing request
  if (options.path === 'status' && request.context['elevate']) {  // A hacky way of determining the context of the requested operation
    return createAdminToken()
  } else {
    return createUserToken(request.user)
  }
}

...
request.context['elevate'] = true
Service.getStatus()

While possible to use, the single TOKEN resolver isn't the most flexible solution. There are probably other ways of solving this problem, but it would be nice if the generated client methods were not static, and that the Service constructor allowed to pass configurations in the constructor that would override the ones set on OpenAPI, eg.:

// in some regular user codepath:
const userClient = new Service({
  token: createUserToken(request.user)
})
userClient.getStatus()

// in some elevated codepath:
const adminClient = new Service({
  token: createAdminToken()
})
adminClient.getStatus()

And yes - I'd like to mention the DI/testing benefits as well.

[cmcnicholas]

We've ended up forking (great project as a base btw) as we wanted some additional's like:

• interfaces for services
• instance based services (not static)
• exposing of the request options as functions
• remove global singleton OpenApi
• add discriminator to unioned namespace
• ability to override catchErrrors
• inject an ErrorFactory
• ability to override parsing of the body

I think that's it https://github.com/yottaltd/openapi-typescript-codegen/tree/feature/yotta-codegen

keep in mind this is only on the fetch templates currently, we have no need for xhr but will be updating the node templates accordingly.

[jacobe]

Thanks a ton @cmcnicholas. Yes I have thought about forking it myself, the .hbs templates seem to be quite easy to work with and customize.

[ferdikoomen]

These tickets are all related to the same "global" objects:
#859
#703
#588

Closing them and keeping the original ticket:
#428

I definitely see the use case, there is also already a PR for this:
PR: #822

[mb21]

For us, the --name option was not flexible enough, so we let the user pass in a whole template for the services: #1268