I recently had the occasion to use React for a project that I'm working on here at Leverege. Coming from an Angular background, React was at once familiar and frightening. After the initial shock of seeing a view contained within controller code had worn off, I quickly came to realize that React is a lightweight, fast UI library that has a lot going for it.

In the end, I learned that while React and Angular are vastly different in the scope of the problems that their creators have sought to solve, there is significant overlap between the two projects in key areas. Let's take a look at two of the pieces of functionality that these projects share in common and see how they are alike and how they differ.

Components

Perhaps the greatest similarity between React and Angular is that they are declarative frameworks that are centered on the use of components to define both appearance and functionality in your application. React provides the React.Component class from which all other components must inherit, while Angular provides a set of helpful interfaces that a class can implement. Both of these strategies for component definition accomplish similar ends. One of the nicest pieces of functionality provided by these libraries are lifecycle hooks for component classes. These are methods that each component can optionally define and are fired any time components go through certain lifecycle events, such as being created, being rendered to the DOM, being updated and being destroyed. This can be very nice when you want a piece of code to run only after a component tree has come into existence or for cleaning up listeners when a component is destroyed.

Views

One stark difference between component classes in these libraries however is the way that their views are defined.

An Angular component defines its view in a separate .html file which is linked to the class using component metadata:

@Component({
 selector: 'app-root',
 templateUrl: './app.component.html',
 styleUrls: ['./app.component.css']
})
class AppCompnent {

Angular also provides some built-in attribute directives that can be used to simplify common templating problems. A directive appears in the form of an attribute on an html element which modifies the appearance or behavior of that element. A classic example is the *ngIf directive which conditionally includes or excludes an element from the DOM based on a boolean criterion:

<div *ngIf="showMe">I'm here!</div>

In React, rather than defining a template in a separate file, all components define a rendermethod which returns the template for the component, generally in the form of JSX, React's templating language. A simple example might look like this:

render() {
   const { showMe } = this.state;
   const element = <div>I'm here!</div>;
   
   return (
       {showMe && element}
   );
}

Note here the use of inline Javascript expressions inside of handlebars and the handy fact that a JSX element (the div in this example) can be assigned to a variable. React does not have built in convenience directives the way Angular does. This can be frustrating when first making the switch from Angular to React, but it does ensure that no special knowledge of the React library is needed to create a dynamic template. Plain vanilla Javascript can be used to include and exclude elements, to create lists of elements or even to switch conditionally between rendering several elements.

State

The largest difference between Angular and React is the way that a component's state is managed. Angular attempts to automate state updates so that a component's view is updated any time one of that component's properties that is bound to the template is updated. On the other hand, React forces the creator of a component to manually define and update the state of that component using the this.state object for initial state and a call to this.setState() any time that one wishes to make an update. If you're used to the magic of Angular, this can seem unnecessary and tedious at first, but I find it much easier to track down issues when I know to a certainty each place within my component where a state may be receiving an update. In addition, when you consider the problems that can arise when trying to effect updates to an Angular application's state from an outside library or plugin, it makes some sense that React doesn't attempt to manage state changes automatically.

React also adopts a philosophy of one-way data flow. This can be tricky coming from an Angular background where state can be shared between components using a custom service class which holds state and is injected into component classes.

Essentially, if any two components in a React application need to share the same piece of application state, that state should be hoisted to a parent component and passed down to the child components through their props—custom properties on JSX elements that are passed to the constructor of the component upon instantiation. The ultimate hoisting of state is the use of Redux, a library especially popular in the React community which represents all application states as a single object, pieces of which can be shared with any component. Although a full discussion of redux is beyond the scope of this particular article, it is well worth your time to investigate the library if you are interested in developing any nontrivial React app.

The Takeaway

Choosing whether to use React or Angular for your next front-end application may come down to a matter of preference. While Angular comes packed with everything you'll need to create even the most complex application, React makes up for its tiny size with a thriving ecosystem of open-source components and its interoperability with many other libraries such as Redux.

Although there are many differences between the React and Angular libraries, they are similar enough when it comes to UI rendering that unfamiliarity with React shouldn't be a reason not to give it a try for your next small project. Who knows, perhaps, like me, you'll even come to accept the idea of your template inline with the rest of your code.