CommunityToolkit / CommunityToolkit/Labs-Windows
Cleanup MarkdownTextBlock state management for rendering lists/paragraphs
- Dominant language
- C#
- Stars
- 482
- Forks
- 89
- PR merge metrics
- No merged PRs in 30d
Description
## Background
_Originally posted by @michael-hawker in https://github.com/CommunityToolkit/Labs-Windows/pull/684#pullrequestreview-2915289262_
> I love the idea of translating lists into text instead of custom UI, makes a lot of sense and resolves a lot of issues with accessibility and copying.
>
> Seeing how this works, I think the crux of the issue is that a List is contained in a Paragraph and we need to modify the properties of the parent paragraph to make this work/look good.
>
> I'm wondering if we can be better here about using parsing to detect this or having the List Renderer make/be a paragraph vs. having to connect state between the paragraph and lists between the renderer. @nerocui any insights here?
>
> I'd have to look at the parsing tree here (I wrote a tool for that actually a few weekends back, but still need to publish it.) Like I just wonder if in all cases a list is just encapsulated by a paragraph and any text before/after is a separate paragraph. If so, we should just make a dedicated "BulletedParagraph" type which will just output the final result that he Listrenderer does vs. it being a thing which needs to coordinate with the general paragraph.
## Problem
The state handling implemented in #684 weaves List-specific state management into the WinUIRenderer, and weaves the WinUIRenderer into the `MyParagraph` and `ListRenderer` classes to access and update this state.
If this pattern is consistently followed for the rest of the `MarkdownTextBlock` implementation, the code will become difficult to maintain and extend.
## Solution
A cleaner approach should be found that still achieves the desired selection behavior on rendered objects without storing implementation state on the `WinUIRenderer` container.
Contributor guide
Assessment
This issue has not been assessed yet.