Fix parsing of JSX with expression #138
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Disclaimer: I am not entirely sure that this is the correct fix, but it does pass the tests. Happy to make changes in the likely case I haven't quite understood this fully.
This fixes the issues mentioned in #136, where this case
<x>{1}</x>
was no longer parsed, and{1}<x/>
caused a panic when converted into an AST (not an issue when converting to HTML).I was first confused about what the expected output should be here, so I looked at micromark for inspiration. Here's what I found:
<x>{1}</x>
as a block level Flow element with an expression (unlike this crate as of alpha.16, which produced a paragraph with an inline JSX text node){1}</x>
into an AST with aroot
element, with two children: the expr, and the JSX tagThis change now makes this crate matches micromark's behavior.
Test program I used
This also removes the
MdxExpressionFlowNok
part of the state, as it wasn't used any more.Fixes #136