In this chapter, you will learn about various patterns, along with their code snippets. However, to run them, you will need the Create React Native App package. I have separated every example into a standalone application that you can launch on your phone or simulator.

To follow along with the examples in this chapter, you will need the following:

• An Android/iOS phone or simulator
• Git, to pull the examples: https://github.com/Ajdija/hands-on-design-patterns-with-react-native

Follow the installation and running instructions from the GitHub page to get started.

We have been using JSX so far, but what does it mean? JSX stands for JavaScript extension. How can it be an extension?

As you probably know, ECMAScript is also an extension to JavaScript (kind of). ECMAScript transpiles to JavaScript. What does this mean? It means that it just transforms ECMAScript code into valid JavaScript code. JavaScript misses out on many features that we like from ECMAScript, such as arrow functions, classes, and destructuring operators.

JSX works the same way. JSX is being transpiled to JavaScript, and its main feature is creating React elements based on the markup you write.
Could we use only JavaScript? Yes. Is it worth it? Most likely not.

Let's check this out in action. This is JSX and ECMAScript:

export default () => <Text style={{marginTop: 30}}>Example Text!</Text>

Now, compare this to pure JavaScript:

export...

React Native is growing fast and changing often. I have selected a curated list of components that are likely to stay within the API for a long time. We will spend some time learning them so that we will be able to proceed faster later on in this book. Any further examples will rely on these components and will assume that you know what these components are for.

So far, we know about three components: View , Text, and StyleSheet. Now, imagine a case where we have a lot of rows to show in the application—something such as table of information pops into my mind. Obviously, it will be a long table, but the screen is small, so we will make it scrollable...

In this section, we will explore how we can handle text input from users. Traditional means of collecting input from so-called forms is divided into two major ways: controlled and uncontrolled. In a native environment, this means either handling any keypress on the React Native side (controlled input), or letting it be handled on the native system level and collecting data in React on demand (uncontrolled input).

This is quite an overlooked feature that came with React version 16. As you should already know, JavaScript can throw errors. Such errors should not break your app, especially if it is from the financial sector. The regular imperative solution from JavaScript is a try-catch block:

try {
    // helloWorld function can potentially throw error
    helloWorld();
} catch (error) {
    // If helloWorld throws error
    // we catch it and handle gracefully
    // ...
}

This approach is hard to use with JSX. Hence, the React team developed an alternative solution for React views. It's called Error Boundaries. Any class component can become an ErrorBoundary component, given that it implements the componentDidCatch function:

class AppErrorBoundary extends React.Component {
    state = { hasError: false };

    componentDidCatch() {
        this.setState({ hasError...

With a Mixin pattern, you mix in a certain behavior with your React components. You kind of inject a behavior for free, and you can reuse the same Mixin in different components. This all sounds great, but it isn't – and you will easily find articles on why. Here, I want to show you this anti-pattern by example.

Instead of shouting Mixins are harmful, let's create a component that is using them and look at what the issues are. Mixins are deprecated, so the first step is finding a way to use them. It turns out that they still live in a legacy way of creating React class components. Previously, instead of ES6 classes, there was a special function called createReactClass...

In this section, we will take a look at quite a different set of patterns, namely, patterns on how to structure your code. Over the years, there have been tens of approaches to styling, and the general rule is this: the more people, the more preferred ways there are.

Hence, the crucial point of setting up the project is selecting your style guide, and your set of defined and precise rules. This will save enormous amounts of time for you as it removes any potential discussion.

In an era of advanced IDEs, it is possible to quickly reformat a whole code base in seconds. This will come in handy in case you need to allow for small future changes to the style of your code.

In this chapter, we learned about view patterns that will be very useful later on in this book. Now we know how to write concise JSX and type check components. We can also compose common built-in components from the React Native library. When we need to, we can write the markup of a simple form and know how to handle the input. We compared controlled and uncontrolled inputs and dove deep into how TextInput works. If some errors occur, our error boundaries will handle the problem.

Finally, we made sure that we have a strict style guide on how to write React Native code, and we enforced these rules by using ESLint.

In the next chapter, we will work on styling the components we have learned. Thanks to this, our application will look nice and professional.