-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parser: Support multiple attribute type, reject invalid #10338
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
packages/blocks/src/api/parser.js
Outdated
|
||
return ( | ||
isStringSource( source ) && | ||
typeof type === 'string' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check if type === 'string' and not typeof type === 'string'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because this is how we differentiate between single and multiple types. I can extract a variable to make this clearer.
It's unclear for which string sources should be considered ambiguous and allow casting, in addition to being inconsistently enforced. Rather than defaulting to leniency, we should enforce the type broadly, reintroducing leniency later if noted issues and need for multiple type support can be reconciled.
Blocker for: #9634
This pull request seeks to enhance the block parser to support multiple
type
, in accordance with JSON schema. This is planned to be used in #9634 to support a nullable string foralign
attribute, representable in JSON schema as multiple type[ "string", "null" ]
.In doing so, it needs to account for how to handle existing behavior of attribute value casting, necessary for attributes sourced ambiguously as strings (e.g. as HTML attribute values). With these changes, casting only occurs for ambiguous string sources of a singular attribute type. For any other attribute, we now reject the attribute value (adopting behavior as if
undefined
, accounting for default value). This may be considered a breaking change, but only in cases where values were assigned of the wrong type, relying on casting to correct. More often, this should help capture unintended serialization (e.g. objects serialized as casted string[object Object]
).Testing instructions:
Verify unit tests pass.