Add optional query string usage in resolvers#453
Add optional query string usage in resolvers#453DanailPenev wants to merge 1 commit intoIBM:masterfrom
Conversation
- Add an optional parameter `useQueryString` to `RequestOptions` which allows callers to use the query string library when generating the resolvers - Add branching logic that uses either query-string or the previous custom logic Signed-off-by: Dani Penev <danailnpenev@gmail.com>
5a1568a to
bd7ccc6
Compare
|
Thanks, Danail. We have a private fix too, but instead of a boolean option we added a function-valued option "queryStringify" so the application could implement whatever strategy it wanted. I was reluctant to propose it here though because I didn't think a global setting is the correct answer when graphql is aggregating REST services from several sources. Using Openapi's style/format/explode properties seems better, since they allow different services to use different strategies, but I'm not sure they cover all the array formats we are likely to run into. What is your experience? |
|
@thomsonbw, I agree with you completely that the change I am proposing is not a perfect solution. Ideally, the parameter serialization should be driven by the OpenAPI spec to conform to the different array query parameter formats there are with an optional override if something is going wrong. I think the boolean option is a good middle ground right now because it exposes a straightforward solution to others who might be struggling with the same issue. It also restores the previously existing functionality that was removed after 2.4.0 when the request library was swapped for |
Summary
useQueryStringtoRequestOptionswhich allows callers to use the query string library when generating the resolvers?x=a&x=b&x=ccompared to the existing behaviour of?x[0]=a&x[1]=b&x[2]=cpackages/openapi-to-graphql/test/example_api6.test.tsso if we want to fully migrate to using it, we might have to add some custom logicMotivation
Testing