fix: support true/false JSON Schemas#311
Conversation
| constructor (json) { | ||
| const isBoolSchema = typeof json === 'boolean'; | ||
| super(isBoolSchema ? {} : json); | ||
| this.isBoolSchema = isBoolSchema; | ||
| } |
There was a problem hiding this comment.
I have the biggest problem here, how to handle it, because we don't support true/false schema from the beginning. This solution both adds boolean schema support, and is also backward compatible. Another solution is to return the schema as boolean, but then we must adjust a lot of functions in another models, which returns array of schemas or single schema. Any thoughts?
There was a problem hiding this comment.
I think it makes sense to keep all schemas as Schema object types. Also, if you return pure boolean types here, checks would need always to be performed as a strict comparison (=== / !===), which sounds pretty error-prone. schema.isBoolSchema sounds like a more readable version and also less error-prone since we can make a statement on "all schemas are represented as Schema objects.
There was a problem hiding this comment.
Yes, you're right :)
There was a problem hiding this comment.
Hmm, yea it is a tricky problem.
In theory, I would never expect an instance of the Schema to be returned to me if the schema was a boolean. Especially since in all other aspects, the parser structure follows the exact type dictated by the specification.
However, I can see the benefits of having this isBoolSchema function 🧐 Not sure what the appropriate approach is here.
There was a problem hiding this comment.
About backward compatible I thought wrong, We didn't support the true/false schemas in parser, because if someone wrote them then had the errors from ajv, because we had broken JSON Schema for spec. I can change the current behaviour and return the boolean in places where we operate on Schema model, but... handling boolean schemas as class is probably less error-prone in templates as @smoya wrote, because then we haven't to check in every place that schema is bool or not. I can only imagine the pain.
Also in current changes I passed for true schema the {} model body and for false the { not: {} } and by this we have two ways for handling Boolean Schemas.
There was a problem hiding this comment.
Yep true, I can see it as a benefit as well in terms of the boolean functions I guess 👍
| { | ||
| title: '/channels/mychannel/publish/message/payload/additionalProperties should be object', | ||
| location: { | ||
| jsonPointer: '/channels/mychannel/publish/message/payload/additionalProperties', | ||
| startLine: 13, | ||
| startColumn: 38, | ||
| startOffset: offset(252, 13), | ||
| endLine: 15, | ||
| endColumn: 15, | ||
| endOffset: offset(297, 15) | ||
| } | ||
| }, |
There was a problem hiding this comment.
When we will merge it asyncapi/spec-json-schemas#63 then this error won't be throw.
jonaslagoni
left a comment
There was a problem hiding this comment.
Added a few things to discuss.
jonaslagoni
left a comment
There was a problem hiding this comment.
Much cleaner 👍 Still got a small comment.
| super(json === false ? {} : json); | ||
| this._json = json; |
There was a problem hiding this comment.
Would it not be possible to change the base check to check for undefined instead of booleans as well?🤔 Or would that create problems? 🤔
Setting _json twice seems like the wrong approach 😅
There was a problem hiding this comment.
The base ctor has:
if (!json) throw new ParserError(`Invalid JSON to instantiate the ${this.constructor.name} object.`);
this._json = json;I don't want to change it, because handling false schemas in base class isn't a good idea. At the moment it's only needed for Schema so I pass empty object as workaround
Setting _json twice seems like the wrong approach 😅
Yep, but it's still "fine" if we make this assignment in child ctor, not in other place :)
There was a problem hiding this comment.
Also checking undefined is not good idea - JSON Schema hasn't undefined type/value
There was a problem hiding this comment.
To my understanding, the base class constructor check, in theory, should only make sure that the received value is not undefined/null 🤔
Therefore you could change that referenced line from a lazy check to strict:
if (json === undefined || json === null) throw new ParserError(`Invalid JSON to instantiate the ${this.constructor.name} object.`);That way you can remove this._json = json; in this constructor.
There was a problem hiding this comment.
Can't see the cases where the argument would be 0, NaN, false, ""
There was a problem hiding this comment.
Perhaps I'm sitting in work too long today 😅 Thanks! Changed.
There was a problem hiding this comment.
haha 😆 That or I have, lets see if others find a problem with this approach 😆
There was a problem hiding this comment.
but even if you put "" or 0 what it's a value in spec? Can we pass something like this in spec itself? Only false has some "value", but only related to Schema object.
There was a problem hiding this comment.
Not that I know of no, hence my suggestion.
The only dilemma I can see could be if the JSON Schema for the specification allowed such values where objects are expected, then it would no longer throw a parser error here. I just don't see the use-case 🤷
jonaslagoni
left a comment
There was a problem hiding this comment.
Is there a reason why you have updated dist/bundle.js?
Other than that it looks good from my perspective 🙂
|
@jonaslagoni Probably when I run the integration tests I didn't check the changes for dist... but it has change on every release :) Could you approve again? |
jonaslagoni
left a comment
There was a problem hiding this comment.
It still detects bundle changes 🙂
5e6b21f to
5ce70ae
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
jonaslagoni
left a comment
There was a problem hiding this comment.
I think we can accept that code smell as we already have a similar one and I dont see any other way of shorting that check 👍
|
@jonaslagoni Thanks! |
|
🎉 This PR is included in version 1.5.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
As in title. As we support JSON Schema draft-07 as schema, then we should also support
true/falseschemas in JSON Schema of our spec and of course in parser. More info #232Related issue(s)
Fixes #232