Kereki Federico - Modern JavaScript Web Development Cookbook: Easy solutions to common web development problems with coverage on React, Node.js, and Microservices

We have prepared a (hidden) component that responds to orientation changes by dispatching an action to update the store, and we know how to code a component that will use the device information. Our main page could look as follows:

If I run the app on a (simulated) Nexus 5 device in portrait mode, we'd see something like the following:

Rotating the device would produce a different view:

In our design, components never use the Dimension API by themselvessince they get the device information from the store, testing the components' behavior for different devices and orientations could be done functionally, without needing to mock anything.

Now, let's start considering several techniques that will come in handy when writing services.

Node runs as a single thread, so if every time it had to call a service, or read a file, or access a database, or do any other I/O-related operation, it would have to wait for it to finish, then attending requests would take a long time, blocking other requests from being attended, and the server would show a very bad performance. Instead, all operations such as those are always done asynchronically, and you must provide a callback that will be called whenever the operation is finished; meanwhile, Node will be available to process other clients' requests.

Node established a standard that all callbacks should receive two parameters: an error and a result. If the operation failed somehow, the error argument would describe the reason. Otherwise, if the operation had succeeded, the error would be null or undefined (but, in any case, a falsy value) and the result would have the resultant value.

This means that the usual Node code is full of callbacks, and if a callback itself needs another operation, that means yet more callbacks, which themselves may have even more callbacks, resulting in what is called callback hell. Instead of working in this fashion, we want to be able to opt for modern promises, and, fortunately, there is a simple way to do so. Let's see how we can simplify our code by avoiding callbacks.

In this chapter, we'll be looking into the following recipes:

• Writing unit tests with Jest
• Adding snapshot testing
• Measuring test coverage
• Using Storybook to preview components
• Debugging your app with react-native-debugger
• Debugging in an alternative way with Reactotron

A new operator, ..., lets you expand an array, string, or object, into independent values. This is harder to explain than to show, so let's see some basic examples:

You can also use it to copy arrays or concatenate them:

You can also use it to clone or modify objects; in fact, this is a usage we're going to meet again later, in , Expanding Your Application, mostly when we use Redux:

This is also useful for writing functions with an undefined number of arguments, avoiding the old style usage of the arguments pseudo-array. Here, instead of splitting an element into many, it joins several distinct elements into a single array. Note, however, that this usage only applies to the last arguments of a function; something such as function many(a, ...several, b, c) wouldn't be allowed:

If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

With what we have done here, you may realize that you have all you could need to handle state, for any application size and you would be right! You could set up the general state for your whole application in the App component (remember we mentioned that App would have more responsibilities?) and you would be able to do the following:

• Pass it down to components by using props
• Update it in answer to events that the components send

This is a perfectly valid solution, and App.state could have all sorts of data for the whole page. App could handle, for example, calling a web service to get the regions for a given country, storing the results in its state, and passing it to our components so that they can be rendered. In our hardcoded version, RegionsInformationTable had the list of countries (where did it get it from?) and handled the requests for regions (by returning hardcoded data). In reality, as we'll see later in this book, getting this sort of information from a server would be handled differently, and at a higher level: RegionsInformationTable would handle rendering the table and leave data gathering to another part of your solution.

Even if you passed web services handling to App, as your application grows in size, this sort of solution may become unwieldy because of the number of data fields you may have to keep track of. We'll find a better scalable solution for this in ,