View #

The most fundamental component for building a UI, View is a container that supports layout with flexbox, style, some touch handling, and accessibility controls. View maps directly to the native view equivalent on whatever platform React Native is running on, whether that is a UIView, <div>, android.view, etc.

View is designed to be nested inside other views and can have 0 to many children of any type.

This example creates a View that wraps two colored boxes and a text component in a row with padding.

class ViewColoredBoxesWithText extends Component { render() { return ( <View style={{flexDirection: 'row', height: 1, padding: 0.2}}> <View style={{backgroundColor: 'blue', flex: 0.3}} /> <View style={{backgroundColor: 'red', flex: 0.5}} /> <Text>Hello World!</Text> </View> ); } }

Views are designed to be used with StyleSheet for clarity and performance, although inline styles are also supported.

Props #

billboarding?: PropTypes.oneOf(['off', 'on']) #

Whether this view should be automatically rotated to face the screen when running on desktop or mobile. Has no effect when in VR.

Note that billboarding overrides any local rotations to the view that may have been set using the transform: [{rotate}] style property.

cursorVisibilitySlop?: PropTypes.oneOfType([PropTypes.number, EdgeInsetsPropType]) #

Used when cursorVisbility='auto' to define how close the cursor must be to the view before it is visible. Default is {top: 0, bottom: 0, left: 0, right: 0} meaning the cursor is visible only when intersecting with the view.

For example, to make the cursor visible when it is within 10 cm of the top or bottom of a view: cursorVisibilitySlop={{top: 0.10, bottom: 0.10, left: 0, right: 0}}

hitSlop?: PropTypes.oneOfType([PropTypes.number, EdgeInsetsPropType]) #

This defines how far a touch event can start away from the view. Typical interface guidelines recommend touch targets that are at least 30 - 40 points/density-independent pixels.

For example, if a touchable view has a height of 20 the touchable height can be extended to 40 with hitSlop={{top: 10, bottom: 10, left: 0, right: 0}}

The touch area never extends past the parent view bounds and the Z-index of sibling views always takes precedence if a touch hits two overlapping views.

onEnter?: PropTypes.func #

Invoked when a interaction method enters a view

onExit?: PropTypes.func #

Invoked when a interaction method exits a view

onHeadPose?: PropTypes.func #

Invoked when the gazing or interacting on a view, the head pose is passed to the event

{nativeEvent: { headMatrix: headMatrixArray, viewMatrix: viewMatrixArray, target: target, source: source, },

onHeadPoseCaptured?: PropTypes.func #

onInput?: PropTypes.func #

Invoked when a user generates input over a view

onInputCaptured?: PropTypes.func #

onLayout?: PropTypes.func #

Invoked on mount and layout changes with:

{nativeEvent: { layout: {x, y, width, height}}}

This event is fired immediately once the layout has been calculated, but the new layout may not yet be reflected on the screen at the time the event is received, especially if a layout animation is in progress.

onMove?: PropTypes.func #

Invoked on when raycast moves within the view

pointerEvents?: PropTypes.oneOf(['box-none', 'none', 'box-only', 'auto']) #

Controls whether the View can be the target of touch events.

  • 'auto': The View can be the target of touch events.
  • 'none': The View is never the target of touch events.
  • 'box-none': The View is never the target of touch events but it's subviews can be. It behaves like if the view had the following classes in CSS:
    .box-none { pointer-events: none; } .box-none * { pointer-events: all; }
  • 'box-only': The view can be the target of touch events but it's subviews cannot be. It behaves like if the view had the following classes in CSS:
    .box-only { pointer-events: all; } .box-only * { pointer-events: none; }

    Since pointerEvents does not affect layout/appearance, and we are already deviating from the spec by adding additional modes, we opt to not include pointerEvents on style. On some platforms, we would need to implement it as a className anyways. Using style or not is an implementation detail of the platform.

style?: style #

backgroundColor color
borderBottomLeftRadius number
borderBottomRightRadius number
borderBottomWidth number
borderColor color
borderLeftWidth number
borderRadius number
borderRightWidth number
borderTopLeftRadius number
borderTopRightRadius number
borderTopWidth number
borderWidth number
opacity number

testID?: PropTypes.string #

Used to locate this view in end-to-end tests.

This disables the 'layout-only view removal' optimization for this view!

You can file an issue on GitHub if you see a typo or error on this page!