Skip to content

fix(parameters): render items format for array-type parameters (#4516)#10886

Open
yogeshwaran-c wants to merge 1 commit into
swagger-api:masterfrom
yogeshwaran-c:fix/array-param-items-format
Open

fix(parameters): render items format for array-type parameters (#4516)#10886
yogeshwaran-c wants to merge 1 commit into
swagger-api:masterfrom
yogeshwaran-c:fix/array-param-items-format

Conversation

@yogeshwaran-c
Copy link
Copy Markdown

Description

For an array-type parameter whose items declare a format, Swagger UI dropped that format from the rendered type column. For example a Swagger 2.0 query parameter:

- in: query
  name: targetUserIds
  type: array
  collectionFormat: multi
  items:
    type: string
    format: uuid

rendered as array<string> instead of something carrying the uuid format. Non-array parameters already render their format (see #4231 / #4245), so the gap was specific to arrays.

Root cause

getType in src/core/plugins/json-schema-5/fn.js builds the array<...> label by recursing into items, but the recursive call only returned the items' type and ignored their format. The calling component src/core/components/parameter-row.jsx then renders the resulting label as-is and appends a separate (format) span derived from the top-level schema's format, which is undefined for array parameters. Net result: array items' format had no rendering path.

This affects Swagger 2.0 and OpenAPI 3.0, which share json-schema-5. OpenAPI 3.1+ uses json-schema-2020-12 and is intentionally out of scope here.

Fix

getType accepts an internal withFormat flag that the array recursion turns on, so item types are emitted inline as <type>($<format>) within the array<...> label, e.g. array<string($uuid)>. The top-level call path is unchanged, so primitive parameter rendering still produces a separate (format) span and existing test expectations hold.

Motivation and Context

Closes #4516.

How Has This Been Tested?

  • New Jest unit tests for getSchemaObjectTypeLabel in test/unit/core/plugins/json-schema-5/fn.js covering: plain primitive, primitive with format (no inline format at top level), array<string>, array<string($uuid)>, array<integer($int64)>, nested array<array<string($uuid)>>, and the exact spec excerpt from the issue.
  • New <ParameterRow/> unit tests in test/unit/components/parameter-row.jsx for both Swagger 2.0 and OpenAPI 3.0 array parameters with and without items format.
  • New Cypress e2e spec at test/e2e-cypress/e2e/bugs/4516.cy.js driven by a small Swagger 2.0 fixture test/e2e-cypress/static/documents/bugs/4516.yaml. Verified locally: 3/3 passing.
  • Existing <ParameterRow/> unit tests still pass (10/10) — the non-array path is unchanged.

Checklist

  • Bug fix (non-breaking change which fixes an issue)
  • My change requires no documentation updates
  • I have added tests to cover my changes
  • All new and existing tests pass

When a query parameter is `type: array` with `items.format`, the format
on the items was dropped from the rendered type column, so e.g.
`items: { type: string, format: uuid }` showed as `array<string>` instead
of `array<string($uuid)>`. Non-array parameters already render their
format via `parameter-row.jsx`, but the JSON Schema Draft 5 `getType`
helper used by Swagger 2.0 and OpenAPI 3.0 never consulted the items
format when building the `array<...>` label.

`getType` now accepts an internal `withFormat` flag that the array
recursion turns on, so item types are emitted as `<type>($<format>)`
inline within the `array<...>` label. The top-level call path is
unchanged, so primitive parameter rendering still produces a separate
`(format)` span and the existing test expectations hold.

Fixes swagger-api#4516
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

Successfully merging this pull request may close these issues.

formats of query parameters are not shown for array-type parameters

1 participant