There Is No div

"Design depends largely on constraints." — Charles Eames, Design Q&A (1972)

Part I was about the runtime. This Part finally writes some interface, and the first thing to notice is how little vocabulary you get.

HTML has around a hundred elements and, more importantly, one completely generic box. A <div> means nothing, contains anything, and can be made to look like anything — which is why the web's component libraries are built almost entirely out of them. React Native has no such element. View looks like the equivalent and is not: measured on 0.81.4, it cannot contain text, and the renderer enforces that with an error rather than a warning.

That single constraint reorganises how you build interfaces, and it is not an oversight. The rest of the primitive set is similarly narrow and similarly deliberate, and this chapter is about what each one actually is — traced through the source, because two of them turn out to render different native components depending on where you put them, which has no equivalent in HTML at all.

This is also the first chapter where the rn try playground is genuinely honest, so the blocks below are real. Where it diverges from a device, I say so at the point it matters rather than in a footnote.

A smaller vocabulary, on purpose

React Native's index.js exposes about seventy exports, of which roughly two dozen are components. The ones you will use constantly are far fewer than that, and each resolves to a specific native class rather than to a generic container.

Traced through the 0.81.4 source, the mapping is literal:

That last row is worth a pause. TextInput does not resolve to one component even within a single platform — single-line and multi-line are different native views on iOS — and the Android name is not merely a different string, it is a different implementation with different behaviour. Part III is largely about consequences of that kind.

Notice what is doing the work. Every box is a View, every piece of text is wrapped in a Text, and the chip is a View containing a Text rather than a styled text element. That nesting is not a stylistic preference — it is the only legal arrangement, and the next section is why.

View cannot contain text

This is the rule that catches everyone coming from the web, and it is enforced rather than advised. The error string lives in both renderers — ReactFabric-dev.js and ReactNativeRenderer-dev.js — and reads:

"Text strings must be rendered within a <Text> component."

So <View>Hello</View> is not a slightly unidiomatic way to write it. On a device it fails.

The reason is layout. A View is laid out by Yoga as a flexbox box: it has a size, children with sizes, and no concept of lines, baselines, word breaking or font metrics. Text needs all of those, and they belong to a text engine rather than a box engine. Rather than making every view carry a dormant text layout system, React Native gives text its own container and requires you to use it.

One playground divergence to state here, because it matters for the block below: react-native-web warns where a device errors. I tested it — rendering a bare string inside a View logs "A text node cannot be a child of a <View>" and then renders it anyway. So the playground will let you do something a device rejects, and this is exactly the sort of place to trust the rule over the demo.

The practical consequence is a habit rather than a burden: every string in a React Native app is wrapped, and after a day you stop noticing. What you gain is that any component receiving children knows whether it is dealing with text or with boxes, without inspecting them.

Text renders a different component when nested

Here is the finding that most changed how I think about these primitives, and it is not visible from the documentation.

Reading Text.js, there is a React context called TextAncestorContext, and the component checks it:

const hasTextAncestor = useContext(TextAncestorContext);
if (hasTextAncestor) {
  // renders NativeVirtualText

And in TextNativeComponent.js, those two are genuinely different host components:

• NativeText → uiViewClassName: 'RCTText'
• NativeVirtualText → uiViewClassName: 'RCTVirtualText'

So a top-level <Text> becomes a real text view, and a <Text> nested inside another becomes a virtual text span — not a view at all, but a run of styled text inside the parent's layout. That is why nested text inherits font properties, participates in the parent's line breaking, and wraps mid-sentence, while a nested View does none of those things.

There is no HTML equivalent. A <span> is a span wherever it appears; its behaviour changes but its identity does not. Here the identity changes.

Look at the first paragraph as it renders: the bold and coloured runs sit inside the same flowing text, breaking across lines wherever the line break falls. That is the virtual-text behaviour, and react-native-web mirrors it structurally — the outer Text becomes a div and the nested ones become span elements carrying a textHasAncestor class, which is a faithful analogue of RCTText against RCTVirtualText.

Image is a view, not a document element

The same "it is a platform view" rule produces a constraint that catches people even faster than the text rule, because it fails silently.

An <img> on the web sizes itself. You give it a src, the browser fetches the bytes, reads the intrinsic dimensions, and reflows the page around them. That works because layout can happen after the image arrives.

React Native cannot do that. Layout runs on the shadow tree, on its own queue, computed before and independently of any network fetch — so an Image with a remote source and no dimensions has nothing to be sized from. I checked what renders: without a width and height it produces a container with a flex basis and no size at all, so it collapses and shows nothing. Add dimensions and they appear.

That is why Image carries static methods a document element would never need. Image.getSize and Image.prefetch both exist on 0.81.4 — the first because you sometimes genuinely must know an image's dimensions before you can lay it out, and the second because deciding layout before the bytes arrive is a worse experience if the bytes then arrive slowly.

The first frame is empty, and that is the entire lesson. Nothing errored, no warning appeared, and the image loaded perfectly well — it simply had no space to occupy. "My image is not showing" is almost always this, and it is a layout question rather than a loading one.

The exception is a bundled image, imported through the asset system rather than fetched: those have known dimensions at build time, so they size themselves. That asymmetry — local images size themselves, remote ones cannot — is worth holding, because it means the bug appears when you switch a placeholder for a real URL.

Context decides what an element becomes

Once you have seen it with Text, the pattern turns up elsewhere, and it is worth naming as a general property: in React Native, the same JSX element can resolve to different native components depending on where it sits.

The clearest second example is in the source alongside the text components: RCTTextInlineImage. An <Image> placed inside a <Text> does not become the ordinary RCTImageView — it becomes an inline image participating in text layout, so it can sit on a line with a baseline like a character rather than as a block.

And TextInput resolves by platform and configuration rather than by nesting: RCTSinglelineTextInputView or RCTMultilineTextInputView on iOS, AndroidTextInput on Android.

That is the underlying reason for a rule you will otherwise memorise: text-related styles inherit from Text to Text and stop at any View. It is not a cascade rule with an exception. It is that the nested elements are part of one text layout, and a View starts a new box.

What the constraint buys

It is worth ending on the trade, because a smaller vocabulary is only a good deal if it returns something.

Every element maps to a real platform view. There is no generic box that the framework has to interpret, which is why View can be a thin wrapper with no drawing code, as Part I found.

The layout engine can be simpler. Yoga only ever lays out boxes. Text layout is delegated to the platform's text engine, which already knows about fonts, scripts, ligatures and line breaking in every language the OS supports — none of which Yoga has to model.

Accessibility gets better defaults. A Text is a text node to the screen reader by construction, because it is a text view on the device.

And the cost is real: you write more wrapping, you cannot style text from a container, and you must know which of the two worlds you are in.

The item worth arguing about is the second one, because delegating text layout is why React Native renders Arabic, Devanagari and emoji correctly without shipping a shaping engine of its own. You inherit whatever the operating system does, which is decades of work nobody on your team had to think about.

That last point is the strongest argument for the whole design, and it is invisible until you need it. Text rendering in the world's writing systems is enormously difficult, and React Native's answer is to not do it — which is only available because Text is a distinct primitive that maps to the platform's own text view.

Common Mistakes

1. Treating View as a div. It cannot contain text, and both renderers throw "Text strings must be rendered within a <Text> component."

2. Setting text styles on a container. A View has no font, and there is no cascade from a box to the text inside it.

3. Rendering a bare string from a conditional. {count && \${count} items`}` is fine while falsy and throws on real data, which is the worst timing.

4. Assuming nested Text is like a nested span. It resolves to RCTVirtualText rather than RCTText — a different native component, not a styled variant.

5. Wrapping runs of text in a View to style them. Crossing a View leaves text layout, so the runs stop flowing as one paragraph.

6. Expecting an Image in a Text to behave like one outside it. It becomes RCTTextInlineImage and sits on the line with a baseline.

7. Assuming TextInput is one component. iOS has separate single-line and multi-line views, and Android has its own implementation entirely.

8. Learning the text rule from the playground. react-native-web only warns and renders anyway; a device errors.

9. Reaching for a generic container that does not exist. There is no element that means nothing — the primitive you pick declares what it is.

10. A remote Image with no width and height. Layout runs before the bytes arrive, so it collapses silently — nothing errors and nothing shows.

Interview Corner

Hands-on

Summary

• React Native has no generic box. View is not a div: it cannot contain text, and the renderer enforces that with an error.
• Each primitive maps to a specific native class — RCTView, RCTText, RCTImageView, RCTScrollView — traced through the 0.81.4 source.
• TextInput is not one component: iOS has separate single-line and multi-line views, and Android has its own implementation.
• Text resolves differently when nested. A TextAncestorContext switches it between RCTText and RCTVirtualText, so nested text is a run rather than a view.
• That is why nested text flows and inherits while a nested View becomes a box sitting on the line — they are different kinds of thing on the device.
• An Image inside a Text becomes RCTTextInlineImage, so context can change an element's identity, which has no HTML equivalent.
• Text is a layout mode, not a box. Inside it, children are runs and styles cascade; outside it, children are rectangles and nothing cascades.
• Text styles on a View do nothing, which is the most common early surprise and follows directly from the two-worlds rule.
• The playground warns where a device errors on bare text in a View, so this is a rule to trust rather than a behaviour to explore.
• Delegating text layout to the platform is what the small primitive set buys: scripts, shaping and emoji work without React Native implementing any of it.

In the next chapter, Text Is Not a Box, we stay inside that second world — what the text engine actually gives you, why numberOfLines is not a CSS property, how fonts behave when the platform owns them, and the alignment rules that stop making sense the moment you expect a box.