Skip to content
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

Merged
merged 7 commits into from
Oct 4, 2018

Conversation

aduth
Copy link
Member

@aduth aduth commented Oct 4, 2018

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 for align 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.

npm test

@aduth aduth added [Type] Enhancement A suggestion for improvement. [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f labels Oct 4, 2018
Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍


return (
isStringSource( source ) &&
typeof type === 'string'
Copy link
Member

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'?

Copy link
Member Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants