-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Feature: [TypeScript] "CollectParameters" to accept params as option-bag #865
Comments
@TiFu maybe this can also be considered in the rewrite of the TS generators? |
Will keep this in mind. |
@TiFu the code-gen changes should be really minimal. Given a function signature like this: fooOperation(fooId: FooId, otherParam: OtherParamType) { The fooOperation({fooId, otherParam}: {fooId: FooId, otherParam: OtherParamType}) { When none of the params are required, then append a default value so that the option-bag can be omitted entirely: fooOperation({fooId, otherParam}: {fooId?: FooId, otherParam?: OtherParamType} = {}) { |
@cspotcode Another option would be to create interfaces for these parameter bags e.g.
What would you prefer? |
No preference. I merely wanted to show that argument destructuring can be
used to avoid any changes to the body of each method. The signature will
be different, but the method body will still refer to each parameter via a
local identifier. No need for property access expressions, e.g.
`params.foo`
…On Wed, Aug 22, 2018, 12:00 PM Tino Fuhrmann ***@***.***> wrote:
@cspotcode <https://github.com/cspotcode> Another option would be to
create classes for these parameter bags
e.g.
interface FooOperationParam {
fooId: FooId,
otherParam: OtherParamType
}
fooOperation(param: FooOperationParam) { }
// if all params are optional:
fooOperation(param: FooOperationParam = {})
What would you prefer?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#865 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAW-uNqQyFcioeOiSZVMTkDTXzlDRBA7ks5uTYAygaJpZM4WF-_Z>
.
|
There were similar suggestions before but nothing has been implemented yet. The use case was that the method contains many optional parameters, which will make the method signature very long in languages such as Java. Related: #641 |
@TiFu If I want to take a stab at implementing this issue, which branch should I base my code on? |
FYI. I've added group parameters support to PHP API client: #1337 |
Hi all, I've tried to add group parameters support to TS Fetch client with some fake parameters to illustrate the change in #1394. https://github.com/OpenAPITools/openapi-generator/pull/1394/files#diff-157014844e879c93896c6ee0805f91ddR1541 is a good starting point to review the change. Please review and let me know if you've any feedback. Disclaimer: I'm no expert in TypeScript Thanks, cc @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) |
Hi all, I have made a PR for Java okhttp-gson API client addressing the same issue of method signatures being too long and inflexible: #1341 However, instead of "group parameters", my solution employs the builder pattern for API requests (#1217) Currently, the vendor extension is x-group-parameters. This name is not appropriate for my PR given my solution. However, having the same vendor extension is ideal. My proposals for a new more general name for this vendor extension are as follows: Anyone have any thoughts on this? |
@Kiran-Sivakumar For typescript, using a destructured options bag is pretty standard. I would be more inclined to use that over a builder pattern.
I found this issue because this is exactly what I am looking for. I have imported and generated FHIR objects, which can have a ton of options, which look like...
Oh look, I need Any update on if/when this may make it in? I'm currently following issue 802. Thanks! |
We have a similar issue, but for us it is the upgrade of the generated API. Some parametes are added in between, some are removed, most are strings so there is no type checking and we only set a few and mostly they are called with undefined. An example is:
Always a pain to find this, and very error prone. |
related: #3349 |
this is implemented for typescript-fetch, see #3349 |
this is implemented for typescript-angular, see #4479 |
Description
I would like the TypeScript code generator to support "CollectParameters" extension, which tells generated methods to accept all parameters as a single object / option-bag instead of multiple, positional arguments.
This extension is described here:
https://blog.apimatic.io/swagger-2-0-extension-for-code-generation-settings-abf602c3869d
openapi-generator version
3.2.1
OpenAPI declaration file content or url
CollectParameters: true
should generate client methods that accept an option-bag of params.Related issues/PRs
Rewrite of TypeScript generators
The text was updated successfully, but these errors were encountered: