Skip to content
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

[Experiment] Markdig based MarkdownTextBlock #480

Merged
merged 38 commits into from Feb 6, 2024

Conversation

nerocui
Copy link
Contributor

@nerocui nerocui commented Jul 23, 2023

This PR adds a new experiment: MarkdownTextBlock. It's a new take on the existing MarkdownTextBlock in the community toolkit. This implementation use the markdig library for parsing markdown syntax.

This initial implementation contains only early work. After this, the plan is to make it more generic, extensible and customizable.

screenshots
image

image

@nerocui nerocui changed the title Added new experiment markdig based MarkdownTextBlock [Experiment] Markdig based MarkdownTextBlock Jul 23, 2023
Copy link

@CosmicPredator CosmicPredator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me...!

Copy link

@itsWindows11 itsWindows11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I guess might want to use ArrayPool and (ReadOnly)Span if possible here.

Copy link
Member

@michael-hawker michael-hawker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a high-level pass, some initial comments. Some things we can do now, some things to think about for later.

@michael-hawker
Copy link
Member

Ah, also looks like XAML Styler needs to be run, @nerocui you can run the script in the root with -Main and it should clean things up.

@niels9001
Copy link
Collaborator

I see that all styling happens in code behind.. would it make sense to move these to separate styles defined in XAML and we load those, when needed, in code behind? Not sure if there would be any performance implications though?

That would allow a developer to easily override a style (like we do here with the current MarkdownTextBlock for the Gallery itself).

@michael-hawker
Copy link
Member

@nerocui I'll try and take this for a spin later this week. Any discussions you think we need to resolve before an initial merge?

When you have a chance, mind rebasing on the latest main?

You'll want to delete your AdditionalAssemblyInfo.cs file and remove the <Version> tag in your src csproj file.

@michael-hawker michael-hawker added the experiment 🧪 Used to track issues that are experiments (or their linked discussions) label Aug 2, 2023
@nerocui
Copy link
Contributor Author

nerocui commented Aug 2, 2023

@michael-hawker I'll address the style in XAML issue later this week, but other than that I don't see anything else for the initial one.

@nerocui
Copy link
Contributor Author

nerocui commented Aug 7, 2023

@michael-hawker the latest commit addressed all the comments so far. Please feel free to take another look.


namespace CommunityToolkit.Labs.WinUI.MarkdownTextBlock;

internal class MarkdownExtensions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this empty?

public string? BaseUrl { get; set; }
public IImageProvider? ImageProvider { get; set; }
public ISVGRenderer? SVGRenderer { get; set; }
public MarkdownThemes Themes { get; set; } = MarkdownThemes.Default;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a property of the control, as otherwise you can't easily set it in XAML here.

Like someone's going to want to do:

<Page.Resources>
    <controls:MarkdownThemes x:Key="MyMarkdownStyle"
        Padding="8,4,0,4"
        H1FontSize="36" ... />
</Page.Resources>

<controls:MarkdownTextBlock MarkdownStyle="{StaticResource MyMarkdownStyle}"/>

Need some thought on the name of the class and property here I think. @niels9001 thoughts?

Also, not sure if straight properties will just work on the themes class. And if we want some defaults defined as resource keys in XAML as well... 🤔

@michael-hawker
Copy link
Member

CI Error:

D:\a\Labs-Windows\Labs-Windows\components\MarkdownTextBlock\src\TextElements\MyList.cs(60,34): 
error CS8524: The switch expression does not handle some values of its input type (it is not exhaustive) involving an unnamed enum value. For example, the pattern '(CommunityToolkit.Labs.WinUI.MarkdownTextBlock.TextElements.BulletType)6' is not covered. [D:\a\Labs-Windows\Labs-Windows\components\MarkdownTextBlock\src\CommunityToolkit.WinUI.Controls.MarkdownTextBlock.csproj]

@michael-hawker
Copy link
Member

Post-release of 8.0, we've seen a number of folks looking for the MarkdownTextBlock control.

@nerocui I know there's still some questions/discussions around structure/API, but if we could at least get a clean build, we could merge a preliminary version in with tasks in a tracking issue, and make it easier for other folks to start picking it up and providing feedback. Do you still have some time to help at least get it to that point? I don't know what else there may be beyond that warning as error I highlighted above. Thoughts?

@nerocui
Copy link
Contributor Author

nerocui commented Nov 21, 2023

@michael-hawker I think that works. I haven't had time to work on this, but I can spend some time to refresh the branch and get to a clean build.

@nerocui
Copy link
Contributor Author

nerocui commented Nov 22, 2023

Refreshed and it works locally. It's getting conflict in the submodule. I'm not sure how to resolve that.

@niels9001
Copy link
Collaborator

Refreshed and it works locally. It's getting conflict in the submodule. I'm not sure how to resolve that.

Could you try to update from main? Hopefully that would resolve the conflict

@nerocui
Copy link
Contributor Author

nerocui commented Nov 22, 2023

@niels9001 I rebased the whole PR from main. Will try again.

@niels9001
Copy link
Collaborator

@Arlodotexe can you help out with the conflict?

@nerocui I think the tooling update isn't required for this PR to work, right?

@nerocui
Copy link
Contributor Author

nerocui commented Nov 22, 2023

@niels9001 That's right. Tooling is not part of this change.

var container = new InlineUIContainer();
var border = new Border();
border.Background = (Brush)Application.Current.Resources["ExpanderHeaderBackground"];
border.Padding = _config.Themes.Padding;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should move assignment of these properties to the template binding.

added label and new icon
@nerocui
Copy link
Contributor Author

nerocui commented Jan 29, 2024

@michael-hawker Fixed the test failure and updated the md file to include new icon and "Labs" label. For the reference error, I wasn't sure how to fix it. Do I need to start a separate PR in the tooling repo to add colorcode?

@michael-hawker
Copy link
Member

@nerocui that's weird, you define the dependency in the dependencies.props so that's all that should be needed... Do you know if you reference the StyleDictionary anywhere?

@Arlodotexe any thoughts?

@nerocui
Copy link
Contributor Author

nerocui commented Jan 30, 2024

@michael-hawker I added ColorCode.Core to dependencies.props, so hope that fixes things.

@michael-hawker
Copy link
Member

@nerocui you already have that defined in your csproj as it's a net standard package, so it shouldn't have to be in the dependencies.props, that file is only for UWP/WinAppSDK/Uno differentiation. So we can put that back. There's something else going on, but not too sure what's going on. @Arlodotexe is going to take a look.

@JoeTomkinson
Copy link

@michael-hawker I added ColorCode.Core to dependencies.props, so hope that fixes things.

No luck, looks as though it's still failing on depenency-related errors to ColorCode.Core

@Arlodotexe
Copy link
Member

I believe I've found the source of the issue. The reference to Microsoft.Toolkit.Uwp.UI.Controls.Markdown 7.1.2 on the UWP head contains a transitive reference to ColorCode.Core that's conflicting with the version being referenced in this component.

Removing the reference to the 7.x MarkdownTextBlock control and cleaning all references to it in the head, the build error is resolved. Only reproduces in Release mode, not Debug.

@michael-hawker We'll have to upgrade the heads in tooling to use the Labs version of MarkdownTextBlock over the 7.x version to resolve the build error.

@nerocui
Copy link
Contributor Author

nerocui commented Feb 2, 2024

@michael-hawker We'll have to upgrade the heads in tooling to use the Labs version of MarkdownTextBlock over the 7.x version to resolve the build error.

Isn't that kind of chicken and egg problem? We'd need to merge this PR to have tooling to reference to.

@michael-hawker
Copy link
Member

Ah, thanks for the insight @Arlodotexe. Another case of Toolkit building toolkit strikes again... any suggestions for a path for us to untangle that? Do we have to do an intermittent PR to the tooling submodule to disable the Markdown stuff or should we create a branch for the tooling here to get a clean CI pass all together and then just snap them together?

@nerocui
Copy link
Contributor Author

nerocui commented Feb 2, 2024

What if in this PR I don't include ColorCode.Core? I'll just add it back in once this one merges and tooling is able to reference the new control.

@Arlodotexe
Copy link
Member

Arlodotexe commented Feb 2, 2024

@michael-hawker Considering that updates to the tooling will affect both the main repo and Labs, we should probably create a new branch in Tooling for this PR. We can set a ToolkitMarkdownTextBlockSourceProject in Build.Directory.props like we did here, and then set it up here so it can be consumed by the app head.

That will fix our CI issue here, but we won't be able to merge the tooling PR (or this one) into main until we have a NuGet package on the PR feed ready to be used in the CommunityToolkit/Windows repo for the other code path.

When we've got that sorted and can close this PR, we'll update tooling once more to use the package from the public NuGet feed instead of the PR feed.

@Arlodotexe
Copy link
Member

Arlodotexe commented Feb 2, 2024

What if in this PR I don't include ColorCode.Core? I'll just add it back in once this one merges and tooling is able to reference the new control.

Tested locally and can confirm that removing references to ColorCode in this component (both code and packages) also solves the build error.

If we go this route, we can postpone updating the tooling repo to use this new component until we've merged the PR, then we can re-add the ColorCode functionality in a later PR. @michael-hawker This seems more reasonable, what do you think?

@michael-hawker
Copy link
Member

What if in this PR I don't include ColorCode.Core? I'll just add it back in once this one merges and tooling is able to reference the new control.

@nerocui that's not a bad idea. Would it be hard to isolate? @Arlodotexe sound good?

@nerocui
Copy link
Contributor Author

nerocui commented Feb 2, 2024

What if in this PR I don't include ColorCode.Core? I'll just add it back in once this one merges and tooling is able to reference the new control.

@nerocui that's not a bad idea. Would it be hard to isolate? @Arlodotexe sound good?

I'll take a look tonight, but the usage of ColorCode is very limited. So it should be easy.

There will be bug in code block, we will fix it in the next PR.
@nerocui
Copy link
Contributor Author

nerocui commented Feb 3, 2024

Updated with colorcode removed. The code block won't render without it. I don't think we need to work around it for now since we are adding it right back after this right?

@niels9001
Copy link
Collaborator

Woohoo! Passed CI

@nerocui
Copy link
Contributor Author

nerocui commented Feb 6, 2024

@michael-hawker shall we merge?

@michael-hawker michael-hawker merged commit d50095f into CommunityToolkit:main Feb 6, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
experiment 🧪 Used to track issues that are experiments (or their linked discussions)
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

7 participants