React vs. Angular components – Part 3

This is the next post from the series about comparison between Angular and React. In the first two posts (part 1 and part 2) we saw the differences between Angular and React components in terms of creation, rendering, and configuration. In this post I will discuss the differences in terms of templates. We have already seen some examples for Angular and React components, but in this post I aim to give you some more details about what we can do with these.

Assigning a template to a component

The idea of a component is to encapsulate logic that is only related to the component itself (and hence not exposing it to the surrounding world). Components usually have a template, which they work on – attach event listeners, read or write properties, etc.


React components have tight relation with the template – each component must render HTML (or any other React component). This is built in React’s mindset as components are the ones to define their templates. Note: talking technically, a React component is actually allowed to return


, which means that the component does not want to return anything. However, these cases have a very limited application. Moreover, React utilizes a virtual DOM, so it needs to know which components it is going to deal with and calculate the differences with the real DOM before the actual rendering.

If you try to return anything else from the

function, you will get the following error:

React error: no template

Note that the

function returns a wrapper for a React component or a HTML element, rather than pure HTML. This is necessary due to the virtual DOM mechanism React employs.


Angular is more flexible as directives are always attached to an existing HTML element. Furthermore, Angular works directly with the real DOM. Thus, we have three ways to assign a template to a directive: inline (similar to React), with an external URL, and no template at all. With Angular we have access to the HTML element a directive has been attached to. So even if we do not specify any template, we can still work with a HTML element (similar to the Decorator pattern in a way and hence the new name in Angular 2).

Generic content

Sometimes one would want to create a component and put whatever content (including other components) inside it (nested at different levels). This enables us to create generic components that can easily be reused. This is a typical scenario the Composite pattern solves. Let’s examine how both Angular and React can help us implement this scenario.


React provides a reserved property that gives access to all the children of the component –

. These are the children provided by the parent of our component, not the component itself.

ReactJS: children demoThis will render a simple (yet nice!) heading followed by whatever the inner HTML of the component is. It is a bit tricky the way

 behaves, though – if there is only one child, then the property return directly this child as a component, otherwise it returns an array. If you just want to render the children (as shown above), you don’t have to care about it. But if you want to do some work with thm, you have to keep this in mind. To help developers reduce checks of the type

, React provides some helper methods to deal with children.


If you only want to work with the children of a HTML element, you can define a decorator directive (as described above) and access them directly from the

 function. You can play with these children as you wish, as you are accessing them directly. To achieve the same idea as shown in the React demo above, however, Angular provides a mechanism, called transclusion.

The transclusion itself compiles the inner HTML of the decorated element, so that any potential bindings inside are satisfied, and provides this HTML for further usage. The simplest way to render it, is by using the built-in directive 


Applying a template to an array of items

Another common scenario is to apply a template to an array of items, i.e. for each item in the array to render some HTML generated from the template with that item as a model. This problem is an implementation of generic template approach described above.


As a React component always works with the entire portion of (virtual) HTML it has rendered, changes in the state triggers a re-rendering. The way it tackles the problem from above is by manually iterating over the array and generating another array with React components.

Running this piece of code, however, will produce the following warning in the developer console:

React: warning for missing key

The problem is that React needs a way to distinguish which element has changed in the array, if you add or remove elements or shuffle the array. In these scenarios it is advised that you add a

 property to the first React component you render from the array. In our example that would be

. The key itself can be a string or number. The idea is that if you happen to shuffle the array, React will ensure that your elements are shuffled in the real DOM, instead of destroyed and recreated.


As you may already have noticed how Angular solves problems, there is a directive for this –

. 🙂

One applies the

directive to a HTML element, which will be repeated for every item in the array. Moreover, a new child scope will be created for every item (where you can, for example, access the current index of the array).


In this post we saw how both React and Angular deal with templates and how one can nest different components and still provide reusable logic. In the next post we will discuss the lifecycle of components, i.e. how we can inject custom logic, for example, just before a component is rendered.