-
Notifications
You must be signed in to change notification settings - Fork 1.4k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
[Discussion] Do we use a .NET Markdown Parser Library instead of our own? #3200
Comments
Thanks for submitting a new feature request! I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future! |
@Kyaa-dost any ideas why the bot added these tags to this issue? |
@michael-hawker I was doing testing with the bot so this have occurred due to that. I have scanned through all the features in the bot and none should be causing this. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Describe the problem this feature would solve
We have a lot of overhead for the
MarkdownTextBlock
supporting Markdown via our own Markdown parser. It may make more sense to refactor on top of a .NET Standard library that's maintained by a larger community, like Markdig.This however, would require updating our
MarkdownRenderer
code to do all the construction from the AST.Describe the solution
Take a dependency on a markdown parser instead of maintaining our own.
Additional context
We were thinking as part of #3062 to separate out the
MarkdownTextBlock
anyway, as it has a lot of dependencies, so this could also contribute to that effort as well to remove the need for the dependency onMicrosoft.Toolkit.Parsers
.If we do this swap, we should convert all of our existing Unit Tests on the Parser to instead test the Renderer and check the translation between the Markdown text scenario and the UI Element tree construction.
This may also just mean we can get rid of the
Microsoft.Toolkit.Parsers
package entirely if we find another open source C# based RSS parser as we don't use that elsewhere in the toolkit currently.Requirements
The text was updated successfully, but these errors were encountered: