React Native / Native descriptions and local interaction / Lesson 3
Styles, Flexbox, and available space
Trace native layout allocation, logical direction, and text growth before adding fixed dimensions to a failing screen.
On this page
Lesson goals
- React Native styles follow a native layout contract
- Allocate remaining row width deliberately
- Respond to the space the component actually receives
React Native styles follow a native layout contract
Style props use JavaScript objects with camelCase property names rather than browser stylesheets. Numeric dimensions normally describe logical layout units, not a guaranteed number of physical display pixels. React Native Flexbox also has defaults that differ from the web, including column as the default main direction and a default flexShrink of zero. Read the chosen container’s direction before interpreting alignment or overflow. A fixed width is not a universal solution for a long label. Identify which ancestor supplies usable width and height, then decide which child should grow, shrink, wrap, or scroll.
Allocate remaining row width deliberately
The first module places a small decorative block beside a text label. Giving the label a flex allocation lets it use the remaining bounded row width. numberOfLines=2 is a product choice to truncate after two lines, not a mandatory repair for every overflow. If full text is essential, allow vertical growth or offer a detail view with equivalent accessible information. StyleSheet.create groups named style objects and can help static checking, but it does not prove contrast, responsive behavior, or performance. Test actual translated and enlarged text rather than only the short synthetic label.
import {View, Text, StyleSheet} from 'react-native';
const styles = StyleSheet.create({
row: {flexDirection: 'row', alignItems: 'center', padding: 16},
mark: {width: 20, height: 20, backgroundColor: 'teal', marginEnd: 8},
label: {flex: 1, flexShrink: 1},
});
export default function App() {
return <View style={styles.row}>
<View style={styles.mark} />
<Text style={styles.label} numberOfLines={2}>Riverside reading workshop</Text>
</View>;
}
The label uses the remaining row width and is limited to two lines.
The host must provide bounded row width. Exact wrapping and native font metrics are derived expectations, not recorded rendering results.
Respond to the space the component actually receives
The second module uses useWindowDimensions, which updates when window information changes. Its illustrative breakpoint chooses row or column composition from current window width. A nested card can receive less width than the window, so its own layout measurement may be the correct input instead. Select breakpoints from content requirements rather than a universal phone/tablet label. Rotation, split-screen, keyboard visibility, and font scale can alter useful space during one session. Preserve reading order and focus meaning when rearranging content. A responsive branch is not evidence that every target configuration has been tested.
import {View, Text, useWindowDimensions} from 'react-native';
export default function App() {
const {width} = useWindowDimensions();
const wide = width >= 600;
return <View style={{flexDirection: wide ? 'row' : 'column', padding: 16}}>
<Text style={{flex: 1}}>Workshop overview</Text>
<Text style={{flex: 1}}>Reading materials</Text>
</View>;
}
Widths below600 choose a column; widths at least600 choose a row.
The600-unit threshold is an example tied to this composition. It is not a universal adaptive-layout recommendation.
Use logical edges and explicit scrolling ownership
Logical start/end spacing supports reading-direction-aware layout, while absolute left/right values describe physical sides. Review their meaning in Arabic instead of blindly reversing every icon or transform. A ScrollView needs a bounded viewport and creates its children eagerly, whereas FlatList addresses larger repeated collections through virtualization. Wrapping multiple scrolling containers together to silence one symptom can create competing gestures or unbounded layout. Decide whether a header stays fixed and which region owns scrolling. Safe-area handling belongs to the selected application integration; do not assume an ordinary padded View accounts for every system inset.
Verify content extremes before declaring layout correct
Review a narrow window, large font scale, long Arabic text, mixed identifiers, empty content, and keyboard-visible forms. Check that essential text remains available and primary actions stay reachable. Do not disable font scaling just to preserve a mockup’s dimensions. Keep the first relevant native layout symptom and a minimal tree when reporting a defect. A source review can explain intended allocation, but actual clipping, touch areas, and accessibility order require the compatible target host. No layout engine, screenshot, simulator, or device validation is performed in this course environment.
Common errors and fixes
A long row label pushes controls offscreen
- Why it happens
- The row has no suitable width-sharing or text-growth contract.
- How to fix it
- Allocate text space deliberately and choose wrapping or justified truncation.
- Prevent it next time
- Test long translations at narrow widths.
A nested pane uses the wrong responsive width
- Why it happens
- Window width was mistaken for the pane’s actual allocation.
- How to fix it
- Measure the relevant component boundary where needed.
- Prevent it next time
- Include split and nested layouts in review.
Arabic padding remains on the unintended edge
- Why it happens
- Physical sides were used for reading-direction semantics.
- How to fix it
- Use logical start/end values where the design calls for them.
- Prevent it next time
- Review both directions with mixed text.
Check your understanding
1. Why is a600-unit breakpoint insufficient for every card in a wide window?
Show worked solution
A card may occupy a narrow column even when the window is wide. Its layout should respond to its available component width and content requirements. Use window dimensions for window-level decisions and a local measurement when the component boundary is narrower.
2. Should every essential title use numberOfLines to remove overflow?
Show worked solution
No. Truncation can hide information the user needs. Decide whether the title can grow, wrap, move to another arrangement, or expose a complete detail view. Verify the accessible label and action remain useful; a visually tidy clipped title alone does not establish a correct task.
Key takeaways
- React Native styles follow a native layout contract
- Verify content extremes before declaring layout correct