Remove parsers#3759
Conversation
|
Thanks RosarioPulella for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
|
So one thing to make sure works is the rendering of the docs for each sample, as this touches that functionality of the sample app. |
|
Hello @RosarioPulella! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
For anyone reviewing, this one is clearest commit by commit. |
michael-hawker
left a comment
There was a problem hiding this comment.
Question on structure here around the Renderer part and its relation to the underlying Parser.
| /// <summary> | ||
| /// A Rendering Superclass for the Markdown Renderer, allowing custom styling of Elements in Markdown. | ||
| /// </summary> | ||
| internal class SampleAppMarkdownRenderer : MarkdownRenderer |
There was a problem hiding this comment.
@RosarioPulella this is what helps display the docs within the Sample App, so I don't think we can remove it? Is it because the MarkdownRenderer would be internalized now? That could be a problem... I think we'd still want that class exposed?
Or did this just move somewhere else?
| <Compile Include="SamplePages\ListViewExtensions\ListViewExtensionsPage.xaml.cs"> | ||
| <DependentUpon>ListViewExtensionsPage.xaml</DependentUpon> | ||
| </Compile> | ||
| <Compile Include="SamplePages\MarkdownParser\MarkdownParserPage.xaml.cs"> |
| /// Generates Framework Elements for the UWP Markdown Textblock. | ||
| /// </summary> | ||
| public partial class MarkdownRenderer : MarkdownRendererBase | ||
| internal partial class MarkdownRenderer : MarkdownRendererBase |
There was a problem hiding this comment.
Yeah, we should still expose the Renderer as part of the Control package as it allows customization of the control.
We just don't want the base parse itself to be exposed. Or are these two things more tightly coupled than we thought?
There was a problem hiding this comment.
I was having trouble keeping it public without having to make every parser class public. I have something I can try.
There was a problem hiding this comment.
The other option we have is to mark the parser bit Obsolete if we need to leave things public? At least by moving it out of it's own package it's a stronger signal until we can refactor the MarkdownTextBlock in the future with #3200.
There was a problem hiding this comment.
I went a head and marked most of the Parsing code as Obsolete.
|
This PR has been marked as "needs attention 👋" and awaiting a response from the team. |
Microsoft.Toolkit.Uwp.UI.Controls.Markdown/Parsers/Constants.cs
Outdated
Show resolved
Hide resolved
|
Completes #3654 |
Fixes #3744
Move Parsing code from
Microsoft.Toolkit.ParsersintoMicrosoft.Toolkit.Uwp.UI.Controls.Markdown. Make parsing code internal as we don't want anyone using our parsers.Remove sample
MarkdownParserPageas it directly uses our parser.PR Type
What kind of change does this PR introduce?
What is the current behavior?
What is the new behavior?
PR Checklist
Please check if your PR fulfills the following requirements:
Other information