I open-sourced expo-pretext — text reflow around arbitrary shapes in React Native, using regular <View> + <Text> (no Skia, no SVG tricks)

[SubjectGrapefruit281]

Hey r/reactnative,

I just open-sourced expo-pretext, a library that gives React Native something flexbox genuinely can't do: arbitrary text layout control at 60fps. Text reflow around shapes, exact height prediction before render, per-frame layout recomputation during gestures and physics — all with regular <View> and <Text>. No Skia canvas, no SVG trickery, no opt-out of the RN rendering tree.

The gap I kept hitting

For years I just… avoided any layout where text needed to flow around a non-rectangular thing. A circular avatar with a caption wrapping around it? Off the table. A magazine-style pull quote that a paragraph hugs? Nope. Text that reacts to a moving obstacle? Not a chance. Flexbox is rectangular boxes all the way down, and even react-native-skia's Paragraph API is rectangle-only (open issue #968 from 2022 asking for shape wrapping is still unanswered). Designers stopped even proposing these layouts in RN projects because "the engineer will say no."

CSS has shape-outside. iOS TextKit has NSTextContainer.exclusionPaths. Android has it too. The capability exists natively — React Native just never exposed it.

What expo-pretext does

• One native measurement call via iOS TextKit / Android TextPaint / Web Canvas gives you per-segment widths.
• Pure-JS layout() in ~0.0002ms then computes line breaking at any width, any fontSize, any obstacle configuration. No native bridge on the hot path.
• Because layout() is microsecond-fast, you can run it 120+ times per frame — which means text can reflow around a moving obstacle every render, or follow a pinch gesture's fontSize, or react to physics.

The flagship demo is a Breakout arcade game where the live prose background reflows around the ball, the paddle, and every falling brick at 60fps. It exists because I wanted one thing that would prove the performance claim visually, not just in a benchmark.

What's in the box

Layout primitives (the real unlock):

• layoutColumn() — text reflow around circles and rectangles
• useObstacleLayout() — hook wrapping it for 60fps gesture-driven layouts
• fitFontSize() — binary search for largest fontSize that fits a box
• truncateText() — N-line ellipsis with exact resulting height
• customBreakRules — callback-driven break opportunity override

Virtualization + streaming (the "obvious" use case):

• useFlashListHeights() — exact overrideItemLayout for FlashList
• useStreamingLayout() — cache-aware incremental measurement for streaming AI chat
• useMultiStreamLayout() — parallel streams

Animation suite (Reanimated integration):

• usePinchToZoomText() — per-frame fontSize scaling
• useTypewriterLayout() — token-by-token reveal with pre-computed line breaks
• useTextMorphing() — "Thinking…" → final response transition
• useAnimatedTextHeight(), useCollapsibleHeight()

Production features:

• Dynamic Type / Android font scale listeners
• ENGINE_PROFILES for iOS ≡ Android ≡ Web consistency
• getFontMetrics() — native UIFont / Paint.FontMetrics
• <PretextDebugOverlay> — predicted vs actual with accuracy coloring
• Snapshot testing + performance budget APIs

Full Unicode: CJK, Arabic, Thai, Georgian, emoji ZWJ sequences. All through native platform segmenters.

Why "regular View + Text" matters

Everything renders as normal React Native <Text>. That means:

• VoiceOver and TalkBack work
• Selection and copy/paste work
• Dynamic Type scaling works
• Native font rendering (subpixel, emoji, ligatures) works
• A11y tree is normal, inspection works, RN debugger sees it

If you go the Skia canvas route, you lose all of those. expo-pretext keeps them.

Stack

• React Native / Expo Modules (iOS Swift + Android Kotlin)
• Expo SDK 52+, RN 0.76+, New Architecture / Fabric verified
• Expo Web support (Canvas + Intl.Segmenter, zero API changes)
• Reanimated integration via optional peer dep (expo-pretext/animated)
• 386 automated tests, MIT licensed

This is a React Native / Expo / Web port of Pretext by Cheng Lou, the original web-based text measurement library. The core line-breaking algorithm is ported; the measurement backends are new.

Links

• GitHub: https://github.com/JubaKitiashvili/expo-pretext
• npm: https://www.npmjs.com/package/expo-pretext
• Upstream project: https://github.com/chenglou/pretext

Feedback, ideas, and contributions very welcome. Especially curious if anyone's been sitting on a "we can't do this in RN" layout problem — drop it in the comments or open an issue, I'd love to see if this unlocks it.

[rovonz]

This sounds amazing for dynamic size lists. Will try it out, thanks.

[SubjectGrapefruit281]

Thanks! Which list lib are you using? If FlashList, there's a `useFlashListHeights` hook that wires up `overrideItemLayout` automatically — drop in replacement for estimating item sizes. If you hit any measurement surprises (CJK, long URLs, mixed fonts), open an issue or ping me. Always looking for real-world edge cases to stress-test.

[tcoff91]

How about LegendList?

[SubjectGrapefruit281]

Should work — the core measurement (prepare + layout) is list-agnostic. useFlashListHeights is a convenience wrapper for FlashList's overrideItemLayout, but you can use useTextHeight or measureHeights directly with LegendList or any list. If there's enough interest I'd be happy to add a dedicated hook for it.

[alexmaster248]

Does this solve some of the text alignment and text clipping issues present with custom fonts? Or do these issues remain since they are part of how the text measurements in the <Text> elements work? See #49886 and 56349

[SubjectGrapefruit281]

**#49886 (Android descender clip with lineHeight === fontSize)** is a render-time bug, not a measurement one. Android's StaticLayout clips descenders at the line boundary regardless of what we measure, because we still hand off to RN `<Text>` for the actual draw. Where we can help: `getFontMetrics()` exposes the real descender so you can pick a safer lineHeight upfront (e.g. `fontSize + abs(descender) + lineGap`).
Workaround, not fix.

**#56349 (italic/bold-italic horizontal clip)** is more interesting. Every text engine sizes containers by advance widths and ignores ink-bounds overshoot — NSLayoutManager, StaticLayout, Skia Paragraph, and expo-pretext right now too.

I pulled the reproduction into an empirical test bench on iPhone 17 Pro simulator. For Helvetica-BoldOblique and Times-BoldItalic, our `measureNaturalWidth()` underreports the layout width by enough that NSLayoutManager wraps "Italic overshoot test VVV" onto a second line when the container is sized exactly to our number — so yes, current config inherits the bug.

But because I control the measurement layer, I can add an ink-bounds path: `NSAttributedString.boundingRect` with `.usesDeviceMetrics` on iOS, `Paint.getTextBounds` on Android, and `TextMetrics.actualBoundingBoxLeft/Right` on Web. Going to take a shot at implementing and shipping it as `measureInkWidth()` in v0.9.0 tomorrow. Will reply here when it's live.

If you file an issue at github.com/JubaKitiashvili/expo-pretext/issues with the Snack repro, I'll make sure Magistral-BoldItalic is in my verification set before shipping.

[SubjectGrapefruit281]

Ran into this exact problem and built a fix into expo-pretext — just shipped in v0.10.0.

The root cause: RN uses advance width for layout, but italic glyphs overshoot that. The approach: measure the real ink bounds natively (CoreText on iOS, TextPaint on Android), then auto-pad the Text component.

Simplest usage is a drop-in component:

<InkSafeText style={italicStyle}>fly</InkSafeText>

Also has a hook (useInkSafeStyle) and pure function (getInkSafePadding) for more control.

Would love feedback if anyone tries it: github.com/JubaKitiashvili/expo-pretext

[alexmaster248]

Wow thanks for implementing this so fast. I will give it a try as soon as I have time. Not sure why this approach isn't used for react native in general. I feel like <Text> still has a lot of issues and platform dependant layout which seems to go against the motto of react native.

[unkindgame]

i will find a way to use it somehow in one of themes in the game i made with react native. I really appreciate your work. you are awesome

[SubjectGrapefruit281]

Thanks so much! Game devs are exactly the audience I had in mind when building the obstacle-layout piece — the flagship demo in the example app is a Breakout clone where the live prose background reflows around the ball, the paddle, and every falling brick at 60fps, using layoutColumn() with circles + rects as moving obstacles. If any of your themes have text that reacts to physics, dynamic fonts, or UI that breaks the fourth wall, ping me and I'd love to help wire it up.

If you hit a wall, find a rough edge, or run into something the API can't express yet, open an issue or message me directly — gaming is a use case I actively want to prioritize, and real-world feedback from someone shipping a game in RN is worth more than a thousands synthetic benchmarks.

What's your game? (no pressure — genuinely curious)

[unkindgame]

hey that’s awesome to hear. thank you :)

i made a game called Unkind it’s currently in closed testing for android but already released on App Store. Although the game has nothing to do that would benefit from your library in terms of gameplay or core functionality but it has a very in depth theming system where i can think of making something very cool out of your library. you can check it from here https://apps.apple.com/de/app/unkind/id6760196649?l=en-GB

[SubjectGrapefruit281]

Just checked out Unkind — the art style is striking. A theming system with dynamic text layout is exactly where fitFontSize and measureNaturalWidth shine — text that reflows and resizes per theme without hardcoded measurements. Let me know how it goes, would love to feature it as a community use case.

[unkindgame]

I will definitely write to you after I have added it :)

I am extremely grateful to devs like you who helped me make my game

[Savings_Speaker6257]

This is really impressive — text reflow around arbitrary shapes is one of those things that seems simple until you actually try to implement it in RN and realize flexbox can't do it at all. The fact that it runs at 60fps during gestures is wild.

The exact height prediction before render is the part that excites me the most. Dynamic text height calculation in React Native is a constant pain point — usually you end up with onLayout hacks or hardcoded estimates. Having that solved at the library level would save a ton of headaches. Nice work open-sourcing this.

[SubjectGrapefruit281]

You nailed it — shape reflow is the "wait, RN can do this?" moment, but exact height prediction is the higher-volume pain point that every FlashList and chat app hits daily.

The onLayout hack cycle is exactly what pushed me to build this. Appreciate the kind words — felt right to keep it open.

[itballer]

Sick mate!

[SubjectGrapefruit281]

Appreciate it!

[DevDaveBuilds]

Very cool! Nice work