# 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> ); } }

> `View`s are designed to be used with `StyleSheet` for clarity and performance, although inline styles are also supported.

### Props #

#### hitSlop {top: number, left: number, bottom: number, right: number} #

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.

#### 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.

#### 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 #

###### Layout Props...

###### Shadow Props...

###### Transforms...

###### backgroundColor color

###### borderColor color

###### borderRadius number

###### borderWidth number

###### opacity number

#### vrenableGazeCollision PropTypes.bool #

Allows the control of gaze collision for this view and all child views, when not enabled no collision checks will be performed within the system. It would be as if that view was not there

You can edit the content above on GitHub and send us a pull request!

Next →