ReactWithMe: What is React.js and Why is it so Popular?

ReactWithMe is a series for aspiring and seasoned React developers who want to strengthen their foundational knowledge of the most popular frontend library. In this blog post, we will explore the who, what, where, when and why of React.js.

In a nutshell, and as stated on the official React website, React.js is “a javascript library for building user interfaces.” But the power and possibilities of React can’t be easily summed up into a tagline or a sentence. It’s much more than this. And even today, its demand and popularity continue to outpace other frontend libraries such as Angular and View.

(Source: gist.github.com/tkrotoff/b1caa4c3a185629299..)

So what makes it so special? Looking at one of the key concepts of React can help us understand why it can turn a developer’s life from a nightmare into a utopia. So let’s talk about components. At the heart of all React applications are components. Components are essentially pieces of user interface that, when combined with other components, create an application with a complex, intricate user interface. When a developer builds a React project, they are essentially building many different independent, isolated, and reusable pieces that assemble to create something bigger. Much like Legos, React allows its users to modify entire applications by adjusting, replacing, or removing pieces without having to necessarily destroy or change the entire structure.

Every React app has at least one component, referred to as the “root” component. This component represents the entire application and additionally contains other “child” components. If we were to draw out the architecture of a React component, it would very much resemble a tree.

(Source: author)

Here we can see a search engine application that has a navigation bar component, results components, and a card component (which has its own widget and text child components for itself). In practical terms, we can take a website like Google and see how this plays out.

Here we can see that the most powerful search engine can be broken down into simple components. Starting from the top we can see a navigation bar with repeating tabs and icons (pink). Below we can see a list of the fetched results (purple) containing a url, title, description and other information. In both the middle and on the right we have card components which, although they look very different, are very similar in setup and likely derive from similar components (green and yellow). Within the rightmost component (yellow) we can break it down even further into child components (blue and red)

When an application is broken down into little Lego pieces, its architecture becomes not only easy to build off of, but the code becomes incredibly easy to modify and scale.

A component is typically implemented as a Javascript class that has some state and render method. State is a crucial component in Javascript, especially in React as it allows you to dynamically change components in response to other changes across the app. That is, it allows your app to react to user input and render the output in the browser. And when there are less states to keep track of, there are fewer chances for bugs and more clarity on how a component relates to another part of the application.

The output of a render method is a React element - a plain javascript object that maps the DOM element. It’s not a real DOM element. It’s just a Javascript object that represents the DOM element. But React keeps a lightweight representation of the DOM in memory which we refer to as the Virtual DOM.

But unlike the real DOM or the virtual DOM, a React DOM is easy and cheap to create and proceeds to work as follows:

• When the state of a component changes, we get a new React element.
• React will then compare this element (and its children) with the previous element.
• It establishes what exactly has changed.
• It then updates a part of the real DOM to keep it in sync with the virtual one.

(Source: author)

What does this mean for developers? Well for one, it means that when building applications with React, we no longer need to work with the DOM API within the browser. In short, we can kiss writing code to create and manipulate the DOM or attach event handlers goodbye. Instead, we simply change the state of our components and React will do the heavy lifting of updating the DOM to match that same state.

For anyone who’s ever attempted to build a to-do list or task manager of some sort, you can probably relate to the process of responding every time a user adds a task. At the apps core, you need to respond to a user request to add a new task by adding their input to the to-do list and then by making sure that all other data across the app displays properly and reflects this new change. In vanilla Javascript, this is completely feasible and doable. There are, in fact, thousands of ways to do so. However, every different way would still prove to be a serious pain because you have to select the list, add the new task to that list, and make sure it renders properly in the html across each page. It becomes even more cumbersome should the application grow to have more nested features and inputs. With React however, things become much easier:

• Imagine you have a state that holds two tasks in an array.
• When you add a new task, you’re basically just adding it to a state.
• Now we have three items in our list. Our state has changed.
• React says, “Ok, so our state has changed. I’m going to re-render your list and all the connecting components to reflect this now.”

You didn't have to write any code to re-render. React did it all for you. Many of us (author included) forget to refresh or re-render applications when a state changes, which can lead to hours of debugging and frustration. The React library allows us to use our mental capacity for bigger technological problems by allowing us to not have to think about when to re-render.

In sum, we are benefitting from the declarative approach of React. Normally when we write javascript, we write code to select elements and then actually change those elements (change inner html, hide, toggle, show things etc.) through events, not declaratively. In React you actually write what you want your html to look like, and you say, “If the state is like this do this, if the state is something else, do this.” Hence the name React, because when the state changes react essential reacts to the state change and updates the DOM.

Conclusion

These are of course only a few of the things that make React so highly popular and in-demand, but it represents a key benefit thats almost immediately noticed by beginners testing the waters with React.

So should I always be using React? Well, of course not. There are plenty of smaller projects and applications out there that will simply be too simple and straight-forward to use React. For example, an application that simply displays data or doesn’t require user interaction will not need to be built with React. However, the more complex the UI becomes and the more the user has a lot of input (clicking things, moving pieces here and there), that’s when React comes into the picture. Social media applications are a prime example of this. People will be updating their feeds, commenting, liking, sharing and essentially reacting to the data on their screen, in such a way that the application should react back. Hmmm…I wonder if there’s a library out that that would be perfect for this 🤔 .