Your use case
What would you like to do?
Rework the rendering of timeline events so we don't just have a TextView with spans and a few drawn overlays, but we can actually add interactive components like scrollable or expandable code blocks or quotes, spoiler tags, inline images, etc.
As a bonus, it would also be nice to modernise the Rich Text Editor (RTE) so it uses Compose components instead of a legacy EditText wrapped in a Composable bridge. However, this is orders of magnitudes more complex and is out of scope.
Why would you like to do it?
- The current rendering is quite efficient, but it was built when the available APIs in Compose were quite limited and so we had to fall back to
TextView instead.
- We also did this so we could have a shared implementation with the RTE library to have a single source of truth, but this has proven problematic: having the RTE as a separate library slows down any new feature or fix related to timeline rendering, we need to make exceptions for corner cases about line spacing, and adds an extra layer of complexity at rendering the messages that's not really needed.
- It's impossible, or at least very complex and awkward to render interactive components given the current implementation. There have been several request to add those and rendering other HTML tags that aren't included in the RTE:
- Having this new rendering could potentially simplify some of our internal code for timeline events and improve performance. Emphasis in could, as this would only be possible if rendering several components would 'cache' the rendering for those independently, allowing us to only re-render those that have changed.
How would you like to achieve it?
- Stop using the RTE's
HtmlToSpanParser for converting HTML into spanned rich text, and depending in the RTE's renderer altogether for rendering events.
- Instead, create our own HTML parser that converts those into either a list of composable functions, or some abstractions over the different tags (paragraph, code block, spoiler, quote, etc.) that can be passed around and then turned into composable functions when needed.
- Stop using
TextView to render the data, use rich Compose components with its own logic, and in the case of pure text, move to using the Composable Text function instead with styles.
- Rewrite the mention/room pills so they work with
Text.
- Still take into account what's the latest composable to render to be able to place the timestamp and resize the message bubble accordingly.
Have you considered any alternatives?
The only alternative would be to keep using the current rendering. Given iOS is already way past this, having interactive code blocks and working on supporting spoiler tags, we should try to reach parity.
Additional context
No response
Are you willing to provide a PR?
Yes
Your use case
What would you like to do?
Rework the rendering of timeline events so we don't just have a
TextViewwith spans and a few drawn overlays, but we can actually add interactive components like scrollable or expandable code blocks or quotes, spoiler tags, inline images, etc.As a bonus, it would also be nice to modernise the Rich Text Editor (RTE) so it uses Compose components instead of a legacy
EditTextwrapped in a Composable bridge. However, this is orders of magnitudes more complex and is out of scope.Why would you like to do it?
TextViewinstead.<table>is not rendered #1551<h2>or header tags #2870How would you like to achieve it?
HtmlToSpanParserfor converting HTML into spanned rich text, and depending in the RTE's renderer altogether for rendering events.TextViewto render the data, use rich Compose components with its own logic, and in the case of pure text, move to using the ComposableTextfunction instead with styles.Text.Have you considered any alternatives?
The only alternative would be to keep using the current rendering. Given iOS is already way past this, having interactive code blocks and working on supporting spoiler tags, we should try to reach parity.
Additional context
No response
Are you willing to provide a PR?
Yes