React Native lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI using declarative components.

React Native is a JavaScript framework for writing real, natively rendering mobile applications for iOS and Android. It’s based on React, Facebook’s JavaScript library for building user interfaces, but instead of targeting the browser, it targets mobile platforms. In other words: web developers can now write mobile applications that look and feel truly “native,” all from the comfort of a JavaScript library that we already know and love. Plus, because most of the code you write can be shared between platforms, React Native makes it easy to simultaneously develop for both Android and iOS.

Similar to React for the Web, React Native applications are written using a mixture of JavaScript and XML markup, known as JSX. Then, under the hood, the React Native “bridge” invokes the native rendering APIs in Objective-C (for iOS) or Java (for Android). Thus, your application will render using real mobile UI components, not webviews, and will look and feel like any other mobile application. React Native also exposes JavaScript interfaces for platform APIs, so your React Native apps can access platform features like the phone camera, or the user’s location.

React Native currently supports both iOS and Android and has the potential to expand to future platforms as well. In this blog, we’ll cover both iOS and Android. The vast majority of the code we write will be cross-platform. And yes: you can really use React Native to build production-ready mobile applications! Some example: Facebook, Palantir, and TaskRabbit are already using it in production for user-facing applications.

When developing in React Native, every Component follows a cycle from when it’s created and mounted on the DOM to when it is unmounted and destroyed. This is what we refer to as the Component lifecycle.

React Native provides hooks, methods that get called automatically at each point in the lifecycle, that give you good control of what happens at the point it is invoked. A good understanding of these hooks will give you the power to effectively control and manipulate what goes on in a component throughout its lifetime.

Our lifecycle is broadly categorized into three parts: Mounting, Updating and Unmounting.

Component cycles

There are multiple reasons a component might re-render, and in each of them different functions are called allowing the developer to update certain parts of the Component.

Component creation

The first cycle is the creation for component, which usually happens the first time a component is encountered in the parsed JSX tree:

1. Constructor
2. componentWillMount
3. render
4. Create All Child Components
5. componentDidMount

Component re-rendering due to re-rendering of the parent component / Component re-rendering due to internal change

1. getDerivedStateFromProps
2. shouldComponentUpdate : — if return yes goto step 3 else stop here
3. getSnapShotBeforeUpdate
4. Rerender All Child Components WIth new Props
5. componentDidUpdate

Component re-rendering due to call to this.forceUpdate

1. getDerivedStateFromProps
2. getSnapShotBeforeUpdate
3. Rerender All Child Components WIth new Props
4. componentDidUpdate

Component re-rendering due to catching an error

Introduced in React 16 as “ErrorBoundaries”. A component can define a special layer which can catch errors and provide a new life-cycle method — componentDidCatch - which allows developers to provide self-repair actions for recovery or graceful handling of errors.

1. render If is populate any error move to step 2 else step 3
2. Show error data
3. Send new props to all child data
4. Thrown error in any life cycle method
5. Parent componentDidCatch()
6. render()

constructor

constructors are the basic of OOP — this is a special function that will get called whenever a new object is created. It’s very important to call a special function super in cases where our class extends any other class that also has a defined constructor. Calling this special function will call the constructor of our parent class and allow it to initialize itself. This is why we have access to this.props only after we’ve initially called super.

As mentioned, constructors are perfect for setting up our Component — create any fields (variables starting with this.) or initialize state based on props received.

This is also the only place where you are expected to change/set the state by directly overwriting the this.state fields. In all other instances remember to use this.setState

DO

• set initial state
• if not using class properties syntax — prepare all class fields and bind functions that will be passed as callbacks

DON’T

• cause any side effects (AJAX calls etc.)

deprecated — componentWillMount

This is a somehow special case — componentWillMount does not differ much from constructor - it is also called once only in the initial mounting life-cycle. Historically there were some reasons to use componentWillMountover constructor see this react-redux issue but please keep in mind that the practice described there is since deprecated.

Many will be tempted to use this function in order to send a request to fetch data and expect the data to be available before the initial render is ready. This is not the case — while the request will be initialized before the render, it will not be able to finish before the render is called.

Additionally, with the changes to React Fiber (post-React 16 beta release) this function might end up being called multiple times before the initial render is called so might result in triggering multiple side-effects. Due to this fact it is not recommended to use this function for any side-effect causing operations.

It is important to note that this function is called when using server-side-rendering while it is counterpart — componentDidMount will not be called on the server but on the client in such case. So if some side-effect is desired on the server part this function should be used as an exception.

A setState used in this function is “free” and will not trigger a re-render.

DO

• update state via this.setState
• perform last-minute optimization
• cause side-effects (AJAX calls etc.) in case of server-side-rendering only

DON’T

• cause any side effects (AJAX calls etc.) on the client side

deprecated — componentWillReceiveProps(nextProps) In the latest version of react native app we can use this function as UNSAFE_componentWillReceiveProps(nextProps)

This function will be called in each update life-cycle caused by changes to props (parent component re-rendering) and will be passed an object map of all the props passed, no matter if the prop value has changed or not since previous re-render phase.

This function is ideal if you have a component whose parts of the state are depending on props passed from parent component as calling this.setState here will not cause an extra render call.

Please keep in mind that due to the fact that the function is called with all props, even those that did not change it is expected the developers implement a check to determine if the actual value has changed, for example:

componentWillReceiveProps(nextProps) {
  if(nextProps.myProp !== this.props.myProps) {
    // nextProps.myProp has a different value than our current prop
    // so we can perform some calculations based on the new value
  }
}

Due to the fact that with React Fiber (post 16 beta) this function might be called multiple times before the renderfunction is actually called it is not recommended to use any side-effect causing operations here.

DO

• sync state to props

DON’T

• cause any side effects (AJAX calls etc.)

static getDerivedStateFromProps(nextProps, prevState)

The new function which main responsibility is ensuring that the state and props are in sync for when it is required. Its main job is replacing componentWillReceiveProps

gDSFP is a static function and as such has no access to this — you are instead expected to return an object, which will be merged into the future state of the component (exactly like working with setState!)

The function is used when a component is updated but also when it is mounted, right after the constructor was called, so you no longer need to use constructor or class property form of state if you want to set initial state from props.

DO

• sync state to props

DON’T

• cause any side effects (AJAX calls etc.)

shouldComponentUpdate(nextProps, nextState, nextContext)

By default, all class-based Components will re-render themselves whenever the props they receiver, their state or context changes. If re-rendering the component is computation heavy (e.g. generating a chart) or is not recommended for some performance reasons, the developer is given access to a special function which will be called in the update cycle.

This function will be called internally with next values of props, state, and object. The developer can use those to verify that the change requires a re-render or not and return false to prevent the re-rendering from happening. In other cases, you are expected to return true.

DO

• use for increasing performance of poor performing Components

DON’T

• cause any side effects (AJAX calls etc.)
• call this.setState

deprecated — componentWillUpdate(nextProps, nextState) In the latest version of react-native we can this functions as UNSAFE_componentWillUpdate(nextProps, nextState)

If the shouldComponentUpdate function is not implemented, or it decided that the component should update in this render cycle, another life-cycle function will be called. This function is commonly used to perform state and props synchronization for when parts of your state are based on props.

In cases where shouldComponentUpdate is implemented, this function can be used instead of componentWillReceiveProps as it will be called only when the component will actually be re-rendered.

Similarly to all other componentWill* functions, this function might end up called multiple times before render so it not advised to perform side-effects causing operations here.

DO

• synchronize state to props

DON’T

• cause any side effects (AJAX calls etc.)

getSnapshotBeforeUpdate(prevProps, prevState)

Other of the two new functions, invoked in the so-called “pre-commit phase”, right before the changes from VDOM are to be reflected in the DOM.

It is used mostly if you need to read the current DOM state, for example, you have an application in which new messages are added to the top of the screen — if a user scrolled down, and a new message is added the screen could move and make the UI harder to use. By adding getSnapshotBeforeUpdate you can calculate current scroll position and maintain it through the DOM update.

Even though the function is not static, it is recommended to return the value, not update the component. The returned value will be passed to componentDidUpdate as the 3rd parameter

DO

• synchronize state to props

DON’T

• cause any side effects (AJAX calls etc.)

componentDidUpdate(prevProps, prevState, prevContext)

This function will be called after render is finished in each of the re-render cycles. This means that you can be sure that the component and all its sub-components have properly rendered itself.

Due to the fact that this is the only function that is guaranteed to be called only once in each re-render cycle, it is recommended to use this function for any side-effect causing operations. Similarly to componentWillUpdateand componentWillReceiveProps this function is called with object-maps of previous props, state, and context, even if no actual change happened to those values. Because of that developers are expected to manually check if given value changed and only then perform various update operations:

componentDidUpdate(prevProps) {
  if(prevProps.myProps !== this.props.myProp) {
    // this.props.myProp has a different value
    // we can perform any operations that would 
    // need the new value and/or cause side-effects 
    // like AJAX calls with the new value - this.props.myProp
  }
}

DO

• cause side effects (AJAX calls etc.)

DON’T

• call this.setState as it will result in a re-render

An exception to the above rule is updating the state based on some DOM property which can be only computed once a component has re-rendered (e.g. position/dimensions of some DOM nodes). Please take extra care to prevent against updating if the value did not in fact change as it might result in a render loop.

componentDidCatch(errorString, errorInfo)

A new addition in React 16 — this life-cycle method is special in the way that it can react to events happening in the child component, specifically to any uncaught errors happening in any of the child components.

With this addition you can make your parent-element handle the error by — for example — setting the error info in state and returning appropriate message in its render, or logging to the reporting system, e.g.:

componentDidCatch(errorString, errorInfo) {
  this.setState({
    error: errorString
  });
  ErrorLoggingTool.log(errorInfo);
}render() {
  if(this.state.error) return <ShowErrorMessage error={this.state.error} />
  return (
    // render normal component output
  );
}

When an error happens, the function will be called with:

• errorString — the .toString() the message of the error
• errorInfo — an object with a single field componentStack which represent the stack trace back to where the error occurred, e.g.:

in Thrower
    in div (created by App)
    in App

componentDidMount

This function will be called only once in the whole life-cycle of a given component and it being called signalizes that the component — and all its sub-components — rendered properly.

Since this function is guaranteed to be called only once it is a perfect candidate for performing any side-effect causing operations such as AJAX requests.

DO

• cause side effects (AJAX calls etc.)

DON’T

• call this.setState as it will result in a re-render

An exception to the above rule is updating the state based on some DOM property which can be only computed once a component has re-rendered (e.g. position/dimensions of some DOM nodes). Please take extra care to prevent against updating if the value did not in fact change as it might result in a render loop.

componentWillUnmount

Use this function to “clean up” after the component if it takes advantage of timers (setTimeout, setInterval), opens sockets or performs any operations we need to close/remove when no longer needed.

DO

• remove any timers or listeners created in the lifespan of the component

DON’T

• call this.setState, start new listeners or timers

Conclusion

In this post, you learned about React js and React Native life cycle hooks.