React - Introduction to Reactjs
Modern apps tend to adhere to what is known as a Single-page app (SPA) model. This is a world where you never navigate to different pages or ever even reload a page. Instead, the different views of your app are loaded and unloaded into the same page itself.
As users interact with our app, we replace the contents of the dotted red region with the data and HTML that matches what the user is trying to do. The end result is a much more fluid experience. You can even use a lot of visual techniques to have your new content transition in nicely just like you might see in cool apps on your mobile device or desktop. This sort of stuff is simply not possible when navigating to different pages.
All of this may sound a bit crazy if you’ve never heard of single-page apps before, but there is a very good chance you’ve run into some of them in the wild. If you’ve ever used popular web apps like Gmail, Facebook, Instagram, or Twitter, you were using a single-page app. In all those apps, the content gets dynamically displayed without requiring you to refresh or navigate to a different page.
Now, I am making these single-page apps seem really complicated. That’s not entirely the case. Thanks to a lot of great improvements in both JavaScript and a variety of third party frameworks and libraries, building single-page apps has never been easier. That doesn’t mean there is no room for improvement, though.
When building single-page apps, there are three major issues that you’ll encounter:
- In a single-page application, the bulk of your time will be spent keeping your data in sync with your UI. For example, if a user loads new content, do we explicitly clear out the search field? Do we keep the active tab on a navigation element still visible? Which elements do we keep on the page, and which do we destroy? These are all problems unique to single-page apps. When navigating between pages in the old model, we just assumed everything in our UI would be destroyed and just built back up again. This was never a problem.
- Manipulating the DOM is really REALLY slow. Manually querying elements, adding children (see Figure 1-5 below), removing subtrees, and performing other DOM operations are some of the slowest things you can do in your browser. Unfortunately, in a single-page app, you’ll be doing a lot of this. Manipulating the DOM is the primary way you are able to respond to user actions and display new content.
- Working with HTML templates can be a pain. Navigation in a single-page app is nothing more than you dealing with fragments of HTML to represent whatever it is you wish to display. These fragments of HTML are often known as templates, and using JavaScript to manipulate them and fill them out with data gets really complicated really quickly. To make things worse, depending on the framework you are using, the way your templates look and interact with data can vary wildly.
For example, this is what using a template in Mustache looks like:
var view = { title: "Joe",
calc: function () { return 2 + 4;
} };
var output = Mustache.render("{{title}} spends {{calc}}", view);
Despite these shortcomings, single-page apps aren’t going anywhere. They are a part of the present, and they will fully form the future of how web apps are built. That doesn’t mean that we have to tolerate these shortcomings. To address this, meet React!
React To The Rescue!
Facebook (and Instagram) decided that enough is enough. Given their abundance of experience with single-page apps, they released a library called React to not only address these shortcomings, but to also change how we think about building single-page apps.
Automatic UI State Management
With single-page apps, keeping track of your UI and maintaining state is hard—and very time-consuming. With React, you need to worry only about one thing: the final state your UI is in. It doesn’t matter what state your UI started out in. It doesn’t matter what series of steps your users may have taken to change the UI. All that matters is where your UI ended up.
React takes care of everything else. It figures out what needs to happen to ensure your UI is represented properly, so all of that state management stuff is no longer your concern.
Lightning-fast DOM Manipulation
Because DOM modifications are really slow, you never modify the DOM directly using React. Instead, you modify an in-memory virtual DOM instead.
Manipulating this virtual DOM is extremely fast, and React takes care of updating the real DOM when the time is right. It does so by comparing the changes between your virtual DOM and the real DOM, figuring out which changes actually matter, and making the least amount of DOM changes needed to keep everything up-to-date in a process called reconciliation.
APIs to Create Truly Composable UIs
Instead of treating the visual elements in your app as one monolithic chunk, React encourages you to break your visual elements into smaller and smaller components.
Just like everything else in programming, it is a good idea to have things be modular, compact, and self-contained. React extends that well-established idea to how we should think about user interfaces as well. Many of React’s core APIs make it easier to create smaller visual components that can later be combined with other visual components to make larger and more complex visual components—kind of like Russian Matryoshka dolls..
This is one of the major ways React simplifies (and changes) how we think about building the visuals for our web apps.
Visuals Defined Entirely in JavaScript
While this sounds ridiculously crazy and outrageous, hear me out. Besides using a really weird syntax, HTML templates traditionally suffered from another major problem. The variety of things you can do inside them other than simply displaying data is limited. If you wanted to choose which piece of UI to display based on a particular condition, for example, you had to write JavaScript somewhere else in your app or use some weird framework-specific templating command to make it work.
For example, here is what a conditional statement inside an EmberJS template looks like:
{{#if person}}
Welcome back, {{person.firstName}} {{person.lastName}}!
{{else}} Please log in.
{{/if}}What React does is pretty neat. By having your UI defined entirely in JavaScript, you get to use all of the rich functionality JavaScript provides for doing all sorts of things inside your templates (as you will see in a few chapters). You are limited only by what JavaScript supports as opposed to any limitations imposed by your templating framework.
Now, when you think of visuals defined entirely in JavaScript, you are probably thinking something horrible involving quotation marks, escape characters, and a whole lot of createElement calls. Don’t worry. React gives you the option to specify your visuals using an HTML-like syntax known as JSX that lives fully alongside your JavaScript. Instead of writing code to define your UI, you are basically specifying markup.
ReactDOM.render(
<div> <h1>Batman</h1>
<h1>Iron Man</h1>
<h1>Nicolas Cage</h1>
<h1>Mega Man</h1>
</div>,
destination );
By using JSX, you are able to define your visuals very easily using a syntax that is very familiar, while still getting all the power and flexibility that JavaScript provides. Best of all, in React, your visuals and JavaScript often live in the same location. You no longer have to jump between multiple files to define the look and behavior of one visual component. This is templating done right.
Just the V in an MVC Architecture
We are almost done here! React is not a full-fledged framework that has an opinion on how everything in your app should behave. Instead, React works primarily in the View layer where all of its worries and concerns revolve around your visual elements and keeping them up to date. This means you are free to use whatever you want for the M and C part of your MVC architecture. This flexibility enables you to pick and choose what technologies you are familiar with, and this makes React useful not only for new web apps you create but also for existing apps you’d like to enhance without removing and refactoring a whole bunch of code.