fix: remove special handling of non-FormData entries

[tim-lai]

Ref: #6033

Description

PR #6025 fix to entries was over-strict on handling js.entries. The extra handling for an js object that may have contained .entries as a key has been removed. The js object is now processed in its entirety without further modification.

Motivation and Context

Fixes #6033

The render failure to expand Models was not previously covered in PR #6025.

How Has This Been Tested?

Additional tests to expand both the Operation and Models have been added.

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.

[char0n]

The logic here is a little bit nonsensical for me here.

createObjWithHashedKeys is used in only one place in codebase, and that's here on line 86.

Then first thing the function does is validate it's input param again but with different predicate statement. This seems redundant and non-compatible with isFunction(js.entries) predicate statement checking if entries is a function instead checking if it's falsy. I recommend dropping following code from the function body.

 if (!fdObj.entries) {
    return fdObj // not a FormData object with iterable
  }

Another thing about createObjWithHashedKeys is that it's super crazy complicated. It's not apparent what is does by reading it. So I'd either put @example tag to functions existing jsdoc to document what is the expected output of this function for particular input (formdata) or create a unit tests for this function.

[tim-lai]

This seems redundant

Internal validation updated to match isFunction for consistency. Internal validation retained for robustness.

The original use of isFunction(js.entries) is a conditional, not a validation

put @example tag

Added a real example

unit tests

Not done for 'createObjWithHashedKeys'. Reason: would be new feature with additional dependencies for isomorphic-form-data for testing purposes. This is also the reason for validating fdObj.entries rather than validating instanceof FormData.

However, there exists a curlify test that tests rendering of the result, which is basis of the added @example tag mentioned above

[char0n]

OK everything clear except one thing.

We're trying to detect if the js is a FormData instance. Why are we not using instanceof FormData operator but rather asserting on the shape of the possible formData instance? swagger-client is integral part of swagger-ui and it makes sure that FormData symbol is always present as global symbol, both in browser and node.js so it's absolutely safe to do so without installing isomorphic-form-data explicitly.

Reason: would be new feature with additional dependencies for isomorphic-form-data for testing purposes

New feature? I'd rather say it's just a dev-dependency used only for tests. But anyway @examples in jsdoc should suffice if function is tested elsewhere in integration.