Open chrisbobbe opened 10 months ago
So, we need the content widgets to work even when their message- and account-data dependencies are absent. Ideally, we would have a way to enforce that such strict dependencies aren't reintroduced.
I noticed that this repo's a-content
label has this description: "Parsing and rendering message contents"
Should we generalize that to something like "Parsing and rendering Zulip content, like in messages"?
Should we generalize that
Sure, done: "Parsing and rendering Zulip HTML content, notably message contents".
However we end up presenting stream descriptions, we'll probably want to show descriptions for views the same way as well. Web app issue: https://github.com/zulip/zulip/issues/29769.
The web app supports Zulip Markdown rendering in contexts other than just message content:
See for example
realm_description
from the server settings on CZO, shown on the login page:And see
rendered_description
on stream objects in the/register
response, shown in stream settings. This screenshot shows links (like[text](link)
) being rendered in some stream descriptions:This kind of thing would be easy to support in our app, except that some of the widgets in
lib/widgets/content.dart
have grown dependencies on data that won't be available in these other contexts. For example,MessageImage
usesRealmContentNetworkImage
, which requires aPerAccountStoreWidget
ancestor. It also links to the lightbox, which is also per-account and additionally pulls data about the message's sender.Currently, the following single line of code (atop #281) actually succeeds in visually reproducing CZO's realm description:
But the links don't work; an error prints to the console when I tap one of them.