Handle structure difference

[ishuen]

Description

See #8218

Motivation and Context

The current json parsing logic is not able to handle OAS3's structure well.

How Has This Been Tested?

Manual test plus unit test

Screenshots (if appropriate):

Screenshot1 https://ibb.co/DLLqygT
Screenshot2 https://ibb.co/HKvSfzL

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.

[tim-lai]

@ishuen Thanks for the issue and PR. I made a comment in issue #8218 for additional information. That said, I also did a quick test in SwaggerUI of the provided definition (both json and yaml formats), and I don't reach the non- parameter.get("schema") case, as referenced in the proposed change:

if (!parameter.get("schema")) {
    console.log("DEBUG: no schema case. parameter:", parameter.toJS())
  }
schema: parameter.get("schema") ? parameter.get("schema", Im.Map()): parameter,

[ishuen]

Hi @tim-lai . Could you provide your test json file?
I tried it with this json file modified from the sample Petstore definition, which is generated from swagger editor . Please check GET /pet/{hasPetId} for boolean case and GET pet/findByTags for enum case.

[tim-lai]

Could you provide your test json file?

from the linked issue: https://github.com/cywhale/test_swagger/blob/main/public/test.json

Please check GET /pet/{hasPetId} for boolean case and GET pet/findByTags for enum case.

Ok, I see the "progression" to the non-schema case now.

Imo, adding the fallback to parameter is incorrect, as a parameter object is different from a schema object. So if no schema is provided, we should return an empty value (Map). Are you on the same environment as the original poster in #8218 ? If so, can you try fallback to Im.Map() instead and see if the devTools errors disappear?

Basically, I think the definition provider should provide a schema, style, or content per the Parameter Object documentation, that matches the boolean or enum case. So this PR should be limited to improving error handling.

[ishuen]

Hi. Thanks for the suggestion, the fallback is replaced by an empty map.

[ishuen]

Fixed the dev env issue.
Root cause: the expected data type of allowedValues defined in Select is array. (See layout-utils.jsx)

[tim-lai]

prefer spread array shorthand

Suggested change

	allowedValues={ Array(...enumValue) }
	allowedValues={ [...enumValue] }

[ishuen]

Got it, thanks.

[tim-lai]

prefer spread array shorthand

Suggested change

	allowedValues={ enumValue ? Array(...enumValue) : booleanValue }
	allowedValues={ enumValue ? [...enumValue] : booleanValue }

[tim-lai]

Root cause: the expected data type of allowedValues defined in Select is array. (See layout-utils.jsx)

Nice! I added a small suggestion to update, otherwise almost there!

[ishuen]

Thanks, the change is applied.

[tim-lai]

@ishuen PR merged! Thanks for the investigation and fix!