Working with Views

When writing in React for the web, you render normal HTML elements (<div>, <p>, <span>, <a>, etc.). With React Native, all of these elements are replaced by platform-specific React components (see Table 2-1). The most basic is the cross-platform <View>, a simple and flexible UI element that can be thought of as analogous to the <div>. On iOS, for instance, the <View> component renders to a UIView, whereas on Android it renders to a View.

Other components are platform-specific. For instance, the <DatePickerIOS> component (predictably) renders the iOS standard date picker (Figure 2-5). Here is an excerpt from the RNTester sample app, demonstrating an iOS date picker. The usage is straightforward, as you would expect:

<DatePickerIOS
  date={this.state.date}
  mode="time"
/>

Figure 2-5. The <DatePickerIOS> component is, as the name suggests, iOS-specific

Because all of our UI elements are now React components rather than basic HTML elements like the <div>, you will need to explicitly import each component you want to use. For instance, we need to import the <DatePickerIOS> component like so:

import { DatePickerIOS } from "react-native";

The RNTester application, which is bundled into the React Native GitHub project, allows you to view all of the supported UI elements. I encourage you to examine the various elements included in the RNTester app. It also demonstrates many styling options and interactions.

Because these components vary from platform to platform, how you structure your React components becomes even more important when you’re working in React Native. In React for the web, we often have a mix of React components: some manage logic and their child components, while others render raw markup. If you want to reuse code when working in React Native, maintaining separation between these types of components becomes critical. A React <DatePickerIOS> component obviously cannot be reused for Android. However, a component that encapsulates the associated logic can be reused. Then the visual component can be swapped out based on your platform. You can also designate platform-specific versions of components if you want, so you could have a picker.ios.js and a picker.android.js file, each with a separate implementation of the same component. We’ll cover this in “Components with Platform-Specific Implementations”.

Using JSX

In React Native, just as in React, we write our views using JSX, combining markup and the JavaScript that controls it into a single file. JSX met with strong reactions when React first debuted. For many web developers, the separation of files based on technologies is a given: you keep your CSS, HTML, and JavaScript files separate. The idea of combining markup, control logic, and even styling into one language can be confusing.

JSX prioritizes the separation of concerns over the separation of technologies. In React Native, this is even more strictly enforced. In a world without the browser, it makes even more sense to unify our styles, markup, and behavior in a single file for each component. Accordingly, your .js files in React Native are in fact JSX files. If you’ve been using vanilla JavaScript when working with React for the web, you will want to transition to JSX syntax for your work in React Native.

If you’ve never seen JSX before, don’t worry: it’s pretty simple. As an example, a pure-JavaScript React component for the web might look something like this:

class HelloMessage extends React.Component {
  render() {
    return React.createElement(
      "div",
      null,
      "Hello ",
      this.props.name
    );
  }
}

ReactDOM.render(
  React.createElement(HelloMessage, { name: "Bonnie" }), mountNode);

We can render this more succinctly by using JSX. Instead of calling React.createElement and passing in a list of HTML attributes, we use XML-like markup:

class HelloMessage extends Component {
  render() {
      // Instead of calling createElement, we return markup
    return <div>Hello {this.props.name}</div>;
  }
}

// We no longer need a createElement call here
ReactDOM.render(<HelloMessage name="Bonnie" />, mountNode);

Both of these will render the following HTML onto the page:

<div>Hello Bonnie</div>

Styling Native Components

On the web, we style React components using CSS, just as we would any other HTML element. Whether you love it or hate it, CSS is a necessary part of the web. React usually does not affect the way we write CSS. It does make it easier to dynamically build class names based on props and state, but otherwise React is mostly agnostic about how we handle styles on the web.

Non-web platforms have a wide array of approaches to layout and styling. When we work with React Native, thankfully, we utilize one standardized approach to styling. Part of the bridge between React and the host platform includes the implementation of a heavily pruned subset of CSS. This narrow implementation of CSS relies primarily on flexbox for layout, and focuses on simplicity rather than implementing the full range of CSS rules. Unlike the web, where CSS support varies across browsers, React Native is able to enforce consistent support of style rules. As with the various UI elements, you can see many examples of supported styles in the RNTester application, which is one of the examples that ships with React Native.

React Native also insists on the use of inline styles, which exist as JavaScript objects. The React team has advocated for this approach before in React for web applications. If you have previously experimented with inline styles in React, the syntax will look familiar to you:

// Define a style...
const style = {
  backgroundColor: 'white',
  fontSize: '16px'
};

// ...and then apply it.
const txt = (
  <Text style={style}>
    A styled Text
  </Text>);

React Native also provides some utilities for creating and extending style objects that make dealing with inline styles a more manageable process. We will explore those later in Chapter 5.

Does looking at inline styles make you twitch? If you’re coming from a web-based background, this is a break from standard practices. Working with style objects, as opposed to stylesheets, takes some mental adjustments and changes the way you need to approach writing styles. However, in the context of React Native, it is a useful shift. We will be discussing styling best practices and workflow in Chapter 5. Just try not to be surprised when you see them in use!