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
Improve list item parsing and indented code blocks parsing #88
Conversation
…nkearns#60 (by adding a parse phase for container)
…rawBlockParser when a container is completed/close)
… using the technique of Open/Closed Blocks and changing UnorderedList type to a block container
… blank line between chunks
It's nice that the actual renderer functions that users write won't actual need to change.
The implementation you have here uses approach (2). The logic lives outside the user's renderer functions. It's nice to see the full implementation, it makes it easier for me to understand which approach I like more. And seeing your implementation, my initial feeling is that I like this approach. It would seem very low-level if the user had to handle those details of loose/tight, and I imagine that most users would just find it frustrating, and wouldn't really find it useful to be able to customize how the render based on loose/tight, but instead would just want that detail taken care of in the implementation. It looks like remark has a similar design. You can see in this example that they parse lists as Also for reference, here is the MDXJS syntax tree reference for lists: https://github.com/syntax-tree/mdast#list. And since the user can map over items in the parsed Markdown Blocks, they also have the option to transform blocks and change whether a list is loose or tight, that gives at least some customizability there if it's needed. |
For future reference, I thought of a 3rd design idea for how to handle loose/tight lists.
I'm not sure there would be any value to approach (3) compared to the current approach, (2). I'm just including it here for future reference. If anyone can think of a use case where approach (3) would be beneficial, I would love to hear about it, though! |
…t.elm and UnorderedListTest.elm).
I’ve let all test cases passed. But since I’ve changed the parser in UnorderedList.elm and OrderedList.elm from the parser of the list to the parser of the list item, the test cases may not be so meaningful as before. Please tell me if I can improve the test cases somehow. |
Excellent! I think it would be nice to have those unit tests exercising the full list parsing, so since that logic has moved up a level I made a commit to run the full parser on those test cases to keep them meaningful: d5d1e13. I think that's a good balance that will keep giving us confidence about those corner cases with the new parsing, so I think the tests are in good shape now 👍 |
It's all looking good to me now! Thanks so much for the hard work @LutSa! 🎉 |
What's in this PR:
Update: How I parse Lists and List items