Text selection fix (WKWebView)

[finallyblueskies]

This PR adds a view that renders chat messages by:

• Converting the LLM chat response into HTML using libcmark_gfm.
• Displaying the HTML in a WKWebView.

This implementation enables free text selection, thereby resolving https://github.com/psugihara/FreeChat/issues/22.

This is my first open-source PR and it's also my first time working with SwiftUI. I would greatly appreciate any suggestions for tackling the above problem, as well as for improving the code or anything else.

To-do list:

• [x] Resolve the initial message sizing issue.
• [x] Fix the resizing issue for messages.
• [ ] Ensure previous styling & theme.
• [ ] Reimplement codeblocks.
• [ ] Connect message functions (copy message, more details etc.) back to Swift
• [ ] Ensure new messages render properly as they stream

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
free-chat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 16, 2024 4:58am

[finallyblueskies]

Doing some testing, even with a fixed height to simulate precalculated dimensions there is a flash of unstyled content. It seems that most of the overhead is parsing and rendering markdown into HTML, noticeable even on my M3:

https://github.com/psugihara/FreeChat/assets/14274086/4d349a51-1609-4730-a3c9-ee78bb3a9571

I think that the only way this approach would move forward is if:

• @psugihara is OK with the drop in responsiveness as the cost for free text selection - perhaps this can be masked, such as an animation to to fade in the views once content is rendered? Might look pleasing while feeling almost as responsive as the previous approach
• A more efficient MD to WKWebView rendering approach is used. No sure what that would be atm

[psugihara]

@psugihara is OK with the drop in responsiveness as the cost for free text selection - perhaps this can be masked, such as an animation to to fade in the views once content is rendered? Might look pleasing while feeling almost as responsive as the previous approach

yeah that seem ok to me if we can get the styles aligned exactly. nice work so far, excited to dig into the diff a bit more.

[finallyblueskies]

I'm not a fan of the complexity of making a WKWebView work, there lots of issues to address before it is production ready.

• Precalculating the size of a message to avoid layout shift is a pretty nuanced problem.
• Masking the performance impact of parsing and rendering HTML is another, there's a risk that this issue might be exacerbated in long conversations or on weaker machines.
• There are likely to be other inconsistencies that are not evident yet - for e.g. I have noticed that it is possible to make independent selections in separate message views as each WKWebView manages its own selection state.

All of this does not make me confident that rendering in a web view is a sustainable approach.

With this in mind I'm experimenting with more native solutions. swift-markdown-ui renders its content in discrete Text(NSAttributedString) blocks. It may be possible to update the library upstream to render multi-paragraph content in a single Text block, or create something specifically on FreeChat.

[finallyblueskies]

Exploring native solutions I found that to implement more complex visual elements like tables, code blocks, or images in SwiftUI, it becomes challenging because the framework doesn't support selection across different views easily. As a result, I doubled down on a WKWebView, enabling the entire conversation thread to be rendered using HTML and CSS. This approach introduces an intermediate layer between the conversation view and the app's other components, requiring a bridge between the web view’s event handling and SwiftUI. This also means that we have two different UI systems in place, which may cause maintenance difficulties later on.

Still, while complex this approach offers significant advantages:

• Entire conversations are selectable.
• Full control over the style and behavior of any HTML content.
• Improved rendering performance, possibly due to more efficient layout processes, which I observed as noticeably faster.

You can observe the interaction in the video below, where the left side is current FreeChat main:

https://github.com/psugihara/FreeChat/assets/14274086/100968c9-ef2a-4b70-b737-eba051df662b

I understand this is a pretty opinionated approach, I will merge it for my FreeChat fork, @psugihara let me know if you're OK with it for FreeChat, in which case I will keep this PR open and complete it here.

[finallyblueskies]

Further exploration of a HTML rendering approach has led me to understand that rendering the whole conversation in HTML makes for a nice, fast prototype but quickly becomes very complex when we need to start re-introducing previous UI elements, functionality and actually efficient rendering. A whole SwiftUI <-> WKWebView API starts to take shape, with lots of duplication and indirection, and while this is a fun exercise it is a completely overblown solution to the problem of having freely selectable messages. I am closing this PR in favor of https://github.com/psugihara/FreeChat/pull/65