Add create requestOpts method to {{classname}}Interface #21708#21709
Conversation
| * @throws {RequiredError} | ||
| * @memberof {{classname}}Interface | ||
| */ | ||
| {{nickname}}RequestConfig({{#allParams.0}}requestParameters: {{#prefixParameterInterfaces}}{{classname}}{{/prefixParameterInterfaces}}{{operationIdCamelCase}}Request, {{/allParams.0}}initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.RequestOpts>; |
There was a problem hiding this comment.
The interface in Runtime.ts is RequestOpts. It might be better to refer to this as {{nickname}}RequestOpts instead of {{nickname}}RequestConfig & creates request options as otherwise the name of the method may be misleading.
There was a problem hiding this comment.
In some libraries it's called request config, such as axios. But it indeed makes more sense to have opts/options here.
| {{/pathParams}} | ||
|
|
||
| const response = await this.request({ | ||
| const requestOpts: runtime.RequestOpts = { |
There was a problem hiding this comment.
You should be able to return the object directly without having a intermediate variable.
There was a problem hiding this comment.
you're right. writing code in mustache is hard
azertyalex
changed the title
|
fix #21708 |
|
What should be my next action to get this merged? |
|
thanks for the PR please cc the technical committee to review moving forward @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02) @davidgamero (2022/03) @mkusaka (2022/04) @joscha (2024/10) |
|
Does anyone in the technical committee have any feedback? |
|
@azertyalex can you please have a look at the issue reported via #22813 ? Looks like it's caused by this change. |
|
I will take a look |
|
@azertyalex reverted this PR in #22814 |
…21708 (OpenAPITools#21709) * feat(types): Add request configuration method to {{classname}}Interface * update docs and samples * refactor: change naming to better mirror openapi context * docs: update typescript-fetch
|
@wing328 @macjohnny Very sorry for the inconvenience. I have made the changes in following pr: #22815 |
* Add create requestOpts method to {{classname}}Interface #21708 (#21709)
* feat(types): Add request configuration method to {{classname}}Interface
* update docs and samples
* refactor: change naming to better mirror openapi context
* docs: update typescript-fetch
* feat(types): Add request configuration method to {{classname}}Interface
…21708 (OpenAPITools#21709) * feat(types): Add request configuration method to {{classname}}Interface * update docs and samples * refactor: change naming to better mirror openapi context * docs: update typescript-fetch
* Add create requestOpts method to {{classname}}Interface OpenAPITools#21708 (OpenAPITools#21709)
* feat(types): Add request configuration method to {{classname}}Interface
* update docs and samples
* refactor: change naming to better mirror openapi context
* docs: update typescript-fetch
* feat(types): Add request configuration method to {{classname}}Interface
4 participants
This PR splits some logic, instead of creating/building the request inline and sending it instantly we now use a function to do this. Functionally there should be no changes.
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master(upcoming7.x.0minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks)"fixes #123"present in the PR description)