You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of #59 we'll need to parse all sorts of MDX components. Currently we use a specific regex to parse components instead.
The MDX components part can be done independently from other
There are some little edge cases with the MDX parsing the way we do it, using a regex:
It's specific to given components
It assumes the components are on a single line
We need to add parsing for more attributes in #63, #64, and #61 to get rid of MDX parser plugins in next, so this part of #59 can be done before the rest of the parser.
I'm thinking of going for a good old scanner and tokenizer with a big switch statement for this, to have the flexibility to gradually add support for all the component syntax (attributes, jsx values with {}, arrays, etc.).
Wishlist
Work on good error messages from the get-go, like make it explicit which attribute is missing or what exactly is malformed when a component doesn't close properly or has a typo.
The text was updated successfully, but these errors were encountered:
As part of #59 we'll need to parse all sorts of MDX components. Currently we use a specific regex to parse components instead.
The MDX components part can be done independently from other
There are some little edge cases with the MDX parsing the way we do it, using a regex:
We need to add parsing for more attributes in #63, #64, and #61 to get rid of MDX parser plugins in next, so this part of #59 can be done before the rest of the parser.
I'm thinking of going for a good old scanner and tokenizer with a big switch statement for this, to have the flexibility to gradually add support for all the component syntax (attributes, jsx values with {}, arrays, etc.).
Wishlist
The text was updated successfully, but these errors were encountered: