bug: numbers follow by a period in a message get rendered as a strange html ordered list

[tyler11177]

Describe the bug

If a user enters a message like "324234. 234234." into the chat, the resulting message in the chat history is a jumbled mess. I believe the renderText function from stream-chat-react sees a string like "324234. 234234." and somehow parses this into a html <ol> element which is then poorly rendered.

To Reproduce

Steps to reproduce the behavior:

1. Enter a string like "324234. 234234." into the chat
2. Look at the resulting message in the chat history

Expected behavior

I would expect the string "324234. 234234." to be rendered in the chat history.

Screenshots

Package version

• stream-chat-react: 11.14.0
• stream-chat-css: 3.13.0
• stream-chat-js:

Desktop (please complete the following information):

• OS: iOS 14.1
• Browser: Chrome
• Version: 123.0.6312.87

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context

See screenshot for logs and code that produces the logs. For example: 324234. 234234. seems to be parsed as

<ol start="324234">
<li>
<ol start="234234">
<li></li>
</ol>
</li>
</ol> 324234. 234234.

[tyler11177]

This also can be replicated in the streamchat demo instance

[myandrienko]

Hi @tyler11177, thanks for reporting!

Our SDK supports Markdown for message formatting. While the result does indeed look a bit odd, this behavior is in line with the CommonMark specification: all lines starting with a number followed by a period are considered to be a numbered list. Two numbers followed by a period produce a nested number list.

If you do not want this behavior, you have several options:

1. Use Markdown escapes: 324234\. 234234\. will not render a numbered list.
2. Customize the way Markdown is parsed by providing your own set of remark plugins (docs).
3. Opt out of Markdown formatting by providing your own renderText function (docs).

[tyler11177]

Hi @myandrienko, thanks for the quick reply! It seems kinda crazy that the resulting message looking like that is the expected behavior. I would recommend looking for a way to improve this product behavior on the StreamChat end but in the meantime we can escape the strings causing this issue.