Add support for multiple @ResponseSchema decorators using oneOf. #58
Conversation
Codecov Report
@@ Coverage Diff @@
## master #58 +/- ##
==========================================
+ Coverage 99.49% 99.52% +0.02%
==========================================
Files 4 4
Lines 199 209 +10
Branches 61 66 +5
==========================================
+ Hits 198 208 +10
Misses 1 1
Continue to review full report at Codecov.
|
Also wrote two tests for that. All tests passed when I ran it.
src/decorators.ts
Outdated
| const oldSchema = | ||
| source.responses[statusCode]?.content[contentType].schema | ||
| if (oldSchema?.$ref || oldSchema?.items?.$ref) { | ||
| // case where we're adding multiple schemas under single statuscode/contentType | ||
| // with single $ref | ||
| const isOldSchemaArray = oldSchema?.items?.$ref | ||
|
|
||
| // delete old schema and integrate into current schema under oneOf | ||
| const schemaObj = { oneOf: [{ ...oldSchema }, schema] } | ||
| responses[statusCode].content[contentType].schema = schemaObj | ||
|
|
||
| if (isOldSchemaArray) { | ||
| delete oldSchema.items | ||
| delete oldSchema.type | ||
| } else { | ||
| delete oldSchema.$ref | ||
| } | ||
| } else if (oldSchema?.oneOf) { | ||
| // case where there's already multiple existing schemas | ||
| const oneOf = _.concat([...oldSchema.oneOf], schema) | ||
| responses[statusCode].content[contentType].schema = { oneOf } | ||
| delete oldSchema.oneOf | ||
| } | ||
|
|
||
| return _.merge({}, source, { responses }) |
There was a problem hiding this comment.
I'm thinking all the deletes makes this a bit hard to read. How about splitting into two branches, something like
if (oldSchema) {
const newSchema = {};
// ...construct newSchema
source.responses[statusCode].content[contentType].schema = newSchema
return source
} else {
return _.merge({}, source, { responses }) // just as before
}
src/decorators.ts
Outdated
| const newStatusCodeResponse = _.merge( | ||
| {}, | ||
| source.responses[statusCode], | ||
| responses[statusCode] | ||
| ) | ||
| const newSchema = makeNewSchema() | ||
| newStatusCodeResponse.content[contentType].schema = newSchema | ||
| source.responses[statusCode] = newStatusCodeResponse | ||
| return source |
There was a problem hiding this comment.
Is there any way we could avoid the _.merge here? How about just assigning to source.responses[statusCode].content[contentType].schema = ...?
Also, I'm not sure if extracting makeNewSchema into another function provides much additional value. We can probably replace it with a simple ternary: const newSchema = oldSchema.oneof ? ... : ...
There was a problem hiding this comment.
Also, I'm not sure if extracting makeNewSchema into another function provides much additional value. We can probably replace it with a simple ternary: const newSchema = oldSchema.oneof ? ... : ...
I agree
Is there any way we could avoid the _.merge here? How about just assigning to source.responses[statusCode].content[contentType].schema = ...?
For this, my original thought with leaving the _.merge in was to keep descriptions for statusCodes. Consider the following example
@ResponseSchema(Model1)
@ResponseSchema(Model2, {description: xxx})If we drop merge and just set schema, then I think that the first description would be lost. Lmk what you think.
There was a problem hiding this comment.
Right, better leave the merge in there for now then.
|
yeah - I'll update some docs. thanks for the fast reviews! |
|
Just wondering, how long would it take for these changes to make it onto the npm registry after merging? Our team would love to use this soon :) |
|
It's out now in v2.1.0 |
Missing some docs, but functionality + tests are there. TS isn't a language I'm very familiar with and this is my first time using lodash, so I'd appreciate any comments/suggestions!
Closes #53