Repository navigation
Description
Is your feature request related to a problem? Please describe.
When EnrichedMarkdownText is placed in a container that sizes to its content (auto width / "hug", e.g. a chat bubble that has a maxWidth but no fixed width), block-level elements collapse: blockquotes and bullet/ordered lists wrap after only a few characters (roughly one short word per line), even though there's plenty of horizontal room.
Plain paragraphs work correctly in the same container — they report a sensible intrinsic width and wrap at the available width. Only block elements collapse. Headings are also fine.
It appears the component reports a very small intrinsic content width for block elements, so a content-hugging parent shrinks the whole view down to that tiny width, and the block then wraps within it. The actual layout is fine when a width is available (see below) — it's the intrinsic-size measurement of blocks that seems off.
Describe the solution you'd like
EnrichedMarkdownText should report an intrinsic content width for block elements (blockquotes, lists) that reflects their real content — i.e. the width of their longest line, the same way paragraphs are measured — so they lay out and wrap correctly inside content-sized/hugging containers without the app having to force a width.
In short: blocks should measure like paragraphs, so EnrichedMarkdownText "just works" in an auto-width parent.
Describe alternatives you've considered
Forcing a fixed/definite width on the container (or on containerStyle): fixes block wrapping, but then every message renders at that fixed width and can no longer hug its content — undesirable for short plain-text messages.
A fixed-width invisible spacer sibling: adding a zero-height View with an explicit width next to the EnrichedMarkdownText forces the parent wide, and blocks then wrap correctly. This confirms the layout works when a width is present — but it requires the app to (a) detect which messages contain block content and (b) hardcode a width, and it forfeits content-hugging for those messages.
containerStyle={{ width: "100%" }}: only helps when an ancestor already has a definite width; in a hugging parent it resolves to the collapsed width and doesn't help.
All of these are app-side workarounds for what looks like an intrinsic-measurement issue in the component.
Additional context
Library version: react-native-enriched-markdown@0.7.3
Platform: iOS (New Architecture)
Minimal repro — render this inside a container that hugs its content (auto width, e.g. alignSelf: "flex-start" with a maxWidth), which is typical for chat bubbles:
<EnrichedMarkdownText markdown={"> This is a normal quote with several words to see where it wraps"} />
Observed: the quote wraps after ~a few characters instead of using the available width. Same for:
<EnrichedMarkdownText markdown={"- item one with a fair amount of text\n- item two with a fair amount of text"} />
Adding a fixed-width child (e.g. an image) or a definite width to the container makes the same content wrap correctly, which is why this looks like an intrinsic-width measurement problem for block elements specifically. Plain paragraphs and headings in the same container are unaffected.
It is also observable that numbered lists have marginLeft applied, but bullet lists do not get this applied to them.
With a regex capturing lists and blockquote, to re-create what I would expect.

We've also noticed this on headings and paragraphs/plain text:
When EnrichedMarkdownText is placed inside a parent that hugs its content (alignSelf: "flex-start" or a flex row, flexShrink: 1, maxWidth, no explicit width), the native view measures itself at one width and draws its text at another. Depending on content and platform this shows up as plain text rendered as a single line that is clipped at the container edge (the container is tall enough for three lines, but the text does not wrap), or headings laid out in a very narrow column so every heading wraps per syllable (H / e / a / d / er / le / v / el / 1). Giving the parent an explicit width makes everything render correctly, and a short message hugs correctly, so the problem is only in how the intrinsic width is reported/used when the parent needs the view's own size. This is the chat-bubble layout (the message wraps at a max width but hugs short content), so it is probably the same root cause as #517, but it also affects plain paragraphs and headings now, not only blockquotes/lists, and the zero-height spacer workaround from #517 does not fix the plain-text case. Reproduction, five cases on one screen:
import { ScrollView, StyleSheet, Text, View } from "react-native";
import { EnrichedMarkdownText } from "react-native-enriched-markdown";
const MAX_BUBBLE_WIDTH = 300;
const LONG_PARAGRAPH =
"text 1 text 1 text 1 text 1 text 2 text 2 text 2 text 2 text 3 text 3 text 3 text 3 text 4";
const HEADINGS = "# Header level 1\n## Header level 2\n### Header level 3";
const SHORT_TEXT = "Short message";
function Bubble({ label, markdown, explicitWidth, withSpacer }) {
return (
<View style={styles.case}>
<Text style={styles.label}>{label}</Text>
<View style={[styles.bubble, explicitWidth && styles.explicitWidth]}>
<EnrichedMarkdownText markdown={markdown} containerStyle={styles.fullWidth} />
{withSpacer && <View style={styles.spacer} />}
</View>
</View>
);
}
export function HuggingWidthRepro() {
return (
<ScrollView contentContainerStyle={styles.screen}>
<Bubble label="1. Plain text, hugging parent" markdown={LONG_PARAGRAPH} />
<Bubble label="2. Headings, hugging parent" markdown={HEADINGS} />
<Bubble label="3. Plain text, hugging + full-width spacer (#517 workaround)" markdown={LONG_PARAGRAPH} withSpacer />
<Bubble label="4. Plain text, explicit width (control)" markdown={LONG_PARAGRAPH} explicitWidth />
<Bubble label="5. Short text, hugging parent (control)" markdown={SHORT_TEXT} />
</ScrollView>
);
}
const styles = StyleSheet.create({
screen: { padding: 16, gap: 16 },
case: { gap: 8 },
label: { fontSize: 12, color: "#888" },
// Chat-bubble contract: hug the content, shrink if needed, never exceed the cap.
bubble: {
alignSelf: "flex-start",
flexShrink: 1,
maxWidth: MAX_BUBBLE_WIDTH,
padding: 12,
borderRadius: 12,
backgroundColor: "#e6e6ea",
},
explicitWidth: { width: MAX_BUBBLE_WIDTH },
fullWidth: { width: "100%" },
spacer: { width: MAX_BUBBLE_WIDTH, height: 0 },
});Observed (screenshots attached, iOS + Android):
- Plain text, hugging parent: both platforms — bubble takes the max width and is tall enough for three lines, but the text is drawn as one line and clipped at the right edge ("text 1 text 1 text 1 text 1 text 2 text 2 text 2 t").
- Headings, hugging parent: iOS — bubble collapses to a tall, ~15pt-wide empty pill, no text visible at all. Android — renders correctly.
- Plain text + spacer: same as case 1 on both platforms, the Correct intrinsic width for block elements (blockquotes/lists) so they wrap in content-sized containers #517 spacer does not help plain paragraphs.
- Explicit width: correct on both platforms, text wraps into three lines.
- Short text: correct on both platforms, bubble hugs the text.
The same layout inside an inverted FlatList (our real chat list, rows = flexDirection: "row" → bubble with flexShrink: 1, maxWidth: 248 → EnrichedMarkdownText with containerStyle={{ width: "100%" }}) shows the heading variant on iOS: the bubble is about 110pt wide and every heading wraps per syllable, while paragraphs, blockquotes and lists in the same list render fine. Android renders the whole list correctly. Scrolling (view recycling) does not change the result. Second screenshot pair attached.
Expected: the view reports an intrinsic width equal to the wrapped text width (capped by the parent's max width), the same as <Text> does, so a hugging parent sizes to the content and the text wraps inside it.
Environment: react-native-enriched-markdown 1.1.1 (also seen on 1.0.2), react-native 0.83.6 (new architecture), react 19.2.0, Expo SDK 55. iOS 26.4 simulator (iPhone 16) and Android 15 emulator (Pixel 8). flavor default (commonmark), no numberOfLines.



Activity
hryhoriiK97 commentedon Aug 30, 2026
Hi @ArnoldsManguzis, thanks for the report and reproduction - we'll investigate this soon!
ArnoldsManguzis commentedon Oct 6, 2026
@eszlamczyk Any news on this?
ArnoldsManguzis commentedon Oct 7, 2026
@eszlamczyk Updated this issue, as we found more iOS based trouble
eszlamczyk commentedon Oct 8, 2026
Hi @ArnoldsManguzis currently we are having a lot of pull request to review so I have to prioritise them, I'll look into this when I have time to resolve bugs (definitely before next minor release)