feat(message-parser): block fallback for unsupported renderers

Merged
GG
4mo ago
+107-36

Proposed changes (including videos or screenshots)

Degrades block AST nodes that a renderer doesn't implement to their raw markup, instead of dropping them.

Problem

Renderers switch on block.type with default: return null. Any block type a given renderer doesn't implement is silently dropped — the content vanishes.

Approach

A block may carry a fallback: a [start, end] offset span into the original message source (see the table / horizontal-rule PRs that populate it). Markup and PreviewMarkup now take an optional source prop (the original message.msg) and, in their default branch, slice source[start..end] and render that text instead of returning null.

Using offsets rather than a copy of the text keeps the AST from being bloated in the persisted/transmitted payload — the source is already available next to the AST in the message. Both web and mobile (React Native) are JS, so the UTF-16 offsets slice identically on both.

Issue(s)

Consumes the fallback offsets produced by the table and horizontal-rule PRs.

Steps to test or reproduce

yarn turbo run build --filter=@rocket.chat/gazzodown then typecheck. Render a Markup with a block carrying a fallback offset span and a source, and confirm the raw markup is shown.

Further comments

Callers that render messages should pass source={message.msg} to Markup/PreviewMarkup so unsupported blocks degrade to text. Mobile should adopt the same default.

Summary by CodeRabbit

  • New Features

    • Unsupported message blocks now remain visible by falling back to their original markup instead of disappearing.
    • Message rendering now preserves the original source text so fallback content can be shown more accurately.

  • Bug Fixes

    • Timestamp content now renders consistently using source-position fallbacks, improving display for parsed messages.
    • Translation and formatted message content now keeps the expected raw text available during rendering.

Task: ARCH-2196