Return of supportedSubmitMethods config parameter (Fixes #3314)

[scottohara]

Description

Restores the supportedSubmitMethods config option from Swagger UI 2.x

Default value is ["get", "put", "post", "delete", "options", "head", "patch", "trace"] (all possible methods supported by OAS 2.x and 3.x), so there is no impact on existing Swagger UI 3.x instances.

As in Swagger UI 2.x, setting the value to an empty array effectively disables Try it Out for all operations.

<OperationContainer> now consults this config value when setting the (existing) allowTryItOut prop that is passed down to the <Operation> component.

Motivation and Context

supportedSubmitMethods was a config option available in Swagger UI 2.x, so the motivation is to bring this previously available feature to Swagger UI 3.x in a way that is compatible with the earlier feature.

Fixes #3314

How Has This Been Tested?

Manual testing of the following scenarios:

• Omitting the supportedSubmitMethods config option. As expected, the default value was applied, displaying the Try it Out button for all operations.
• Specifying a subset of methods, supportedSubmitMethods: ["get","delete"]. As expected, the Try it Out button was shown for only GET and DELETE operations.
• Specify no methods (empty array), supportedSubmitMethods: []. As expected, the Try it Out button was not displayed for any operations.

Screenshots (if appropriate):

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[shockey]

LGTM

[sumanthjoel]

Hi,

I am new to swagger. I am running SwaggerUI as a docker container (swaggerapi/swagger-ui) and i want to try the above feature (supported_submit_methods) in the UI. How can I use this?

More info: I want to document the APIs developed in Golang, so I am using go-swagger to generate the spec file and passing the spec file to Swagger UI using the env variable SWAGGER_JSON.

[shockey]

Hey @sumanthjoel! Please open a new support issue if you need help with something 😄