React: A front-end developer’s perspective

In a previous article, Devbridge’s Co-founder and Senior Software Architect, Tomas Kirda, explained why in his opinion React is quickly becoming the framework of choice for developers. For those who have yet to work with React or who are considering working with React, I will explain what React is, how it works, and how to get along with it a little easier from a front-end developer’s perspective. I also will share some tips that I wish I knew at the beginning of learning React without getting deeply technical.

What is React?

In March 2013, Facebook released a user interface library for building web applications out of components and called it React. For those familiar with Model View Controller (MVC), React is similar to views (the V in MVC). In essence, React is responsible for an applications’ user interface (UI) -- how it looks now or how it will look under certain conditions. These conditions, or properties, can change and are stored inside an object called state. When the state changes, the UI gets updated. React doesn’t make UI development easier, but it makes maintenance more enjoyable, because building with components makes it easier to scale an application.

Since React is just views, Facebook has FLUX -- an architecture for creating data layers in JavaScript applications. If a router is added to the list along with other common components, the result is a stack functionally similar to the Angular framework. Hence React alone is not directly comparable with Angular.

React’s Two Main Building Elements: Components and State

An application is built with components. In .html element is added, which serve as a holder for root component. The root component holds other components, which can have child components and so on.

React Root Component

The root element acts like a layout and contains components such as the header, which has child components, such as a menu or notification counter. Another top level component could be a sidebar.

React Layout Component

Almost every component contains instructions on how to build HTML DOM (JSX) and methods that handle some actions.

In the above example, the top component is “Layout,” which means that it will hold all the child element states. The notifications count itself is stored in state and that state is at the Layout component. Using props, the count is passed on to children so they know what to show. When the button “Mark as read” is clicked, the count should decrease. One thing to note, however, is that functions that actually set the state are also at the top component (the Layout component in this example) and are passed down to children just as any other props.

New Terminology - JSX and Virtual DOM

All frameworks have their own terminology. Therefore, certain things need to be named so that individuals can identify them while communicating with each other. React had some words that were new to me. The most magical sounding were Virtual DOM and JSX.

Let’s start with the easier to understand of the two -- JSX. You can write React components in JavaScript or you can use alternative JavaScript syntax, JSX. Following is an example:

Alternative Javascript Syntax

As you can see, writing markup in JSX is more intuitive, so most developers choose this way. However, JSX must be transformed into javascript, because browsers do not understand JSX. Since JSX is still JavaScript, developers cannot use the “class” property. Rather, “className” should be used. This is the most common mistake I make writing React components. Another sometimes annoying thing, is that the components’ markup can contain only one root markup element.

React Component Markup
If one uses <div>text {variable}</div>, the {variable} part will be wrapped with a span, unless it is wrapped with something else. However, this has been changed in React version 15. Facebook updated React so the DOM can be lighter and cleaner -- hence a good reminder that developers should use latest versions.

Virtual DOM was Difficult to Understand

Virtual DOM took me a little longer to understand. The typical DOM is what you see when you open DevTools inside a browser.

React DOM

Virtual DOM is more like a clone of the real DOM. React components (even written in JSX) turn out to be JavaScript objects. These objects are later rendered into HTML. A collection of these objects is Virtual DOM. When the state changes, React updates Virtual DOM, then compares it with the previous Virtual DOM version and sees what has changed. Only the updated markup is injected into the browser. This is fast, because the browser needs only to update some nodes of the DOM. For example, if you have notifications and view one, the notification counter has to be updated, so only the affected places well be rerendered.

Virtual DOM

Additional roadblocks and tips

Prior to giving some tips and my overall perspective on React, I thought it would be helpful to highlight some of the more confusing parts of the library and features that I did not like.

Confusing parts

  • Initially, building markup with components seemed clear. In most cases you build your whole markup with components including layout, and so on. So header becomes component, and layout becomes component. Even a router is the component, and in most cases it will be the top most component.

  • Components such as Router and Document Title will not produce any markup, they just need to be at the top, because it is the way they function.

  • React does not do two-way event binding, though it is possible. Rather, it uses one-way binding and one-way data flow. The Controller view (top view component, such as an About Us page) owns all click events, and knows all data. Child components are not that smart, actually they should be dumb, they just wait for state (which they get through properties) to change and update the output. Therefore, data flows from the top component down to child components.

  • It’s a bad idea to manipulate real DOM if you do not understand how React works. If you change something in real DOM directly, React can overwrite that change on the next component rendering. Therefore, jQuery plugins should be used carefully.

  • Initially, some of the React code looked complicated. However, it was because I was not very familiar with plain JavaScript. Object manipulation functions, such as map or assign looked strange at first. The better one is with plain JavaScript, the better in React.

  • React is very fast, but be watchful of performance. At a minimum, understand how React lifecycle methods and especially render method works. If you don’t, you will lose the speed of React.

Parts I did not like

  • Heavy DOM; I mean attribute “data-reactid” on every single DOM node. However, since version 15, Facebook changed the way React is mounting component) and now DOM is lighter.

  • Since React is a views library, you have to use community-built components or build them yourself for some functionality. However, this is not a problem for everyone. Most of the community builds modules that are good enough, and since the community is large, you have many components to choose from.

  • Most bothersome is that some developers have hard-coded styles on their components. To override, you need to use “!important” in your styles or look for other ways, such as resetting component properties.

  • I’m not a big fan of writing styles inside JSX.


  • Don’t break everything into components. You need to structure your code, but don’t create a component for every paragraph. However, creating components for text input is a good idea.

  • Don’t try to make components that do everything. Dumber components versus one smart component is a better idea.

  • Having some skill with JavaScript really helps to get started and progress faster, though React does not require someone to be a JavaScript ninja to create React components.

  • Use self closing tags for all empty elements; React will take care of it.

  • Use propTypes (definition of properties that component expects to receive) to save time for yourself and others.

  • Don’t set this.props, use this.state.

  • Use React Tools

  • Know all React lifecycle methods. “shouldComponentUpdate” will save your application's’ performance.

  • To transform JSX to JavaScript you will most likely use Babel. Actually there’s no big reason not to use ECMAScript 6 features, which makes JavaScript language feel a bit more mature.

Conclusion: Keep it Simple

All in all, React is not really difficult. There are many great tutorials out there. Just make sure that you look at the most updated, because the front-end libraries and frameworks get updated often. From my own experience, the most important lesson I learned is that components should be light, small and do as few things as possible. That resulted in my refactoring big, smart components into smaller ones.

Looking for more on React?

To React or Not to React?

Pros and Cons of React Native - Mobile Apps with Javascript