Does React Native have a 'Virtual DOM'?

Question

From ReactJS wiki page about Virtual DOM:

React creates an in-memory data structure cache, computes the resulting differences, and then updates the browser's displayed DOM efficiently. This allows the programmer to write code as if the entire page is rendered on each change while the React libraries only render subcomponents that actually change.

In other words, Virtual DOM allows us to improve performance by avoiding direct manipulations with DOM.

But what about React Native?

We know that in theory on other platforms there are native views and UI components. There is nothing about DOM itself. So can we say React Native has "Virtual DOM" there or we're talking about something else?

For example, there is a section in Weex specs which describes methods to work with DOM-tree directly. And my assumption is that potentially we can think React Native should have some sort of DOM-tree too as well as "Virtual DOM" abstraction layer which is the main idea of React itself.

So my question is:

Does React Native have some sort of "Virtual DOM" (or its representation) and if so, how this "Virtual DOM" is ported to various platforms?

UPDATE:

The goal of this question is to shed some light on how React Native manage rendering of native UI components. Is there any specific approach and if so, how it's officially called?

UPDATE 2:

This article describes new React architecture called Fiber which looks like the answer on this question.

Answer 1

In Short

Well.. in essence, yes, just like Reactjs's Virtual DOM, React-Native creates a tree hierarchy to define the initial layout and creates a diff of that tree on each layout change to optimize the renderings. Except React-Native manages the UI updates through couple of architecture layers that in the end translate how views should be rendered while trying to optimize the changes to a minimum in order to deliver the fastest rendering possible.

A more detailed explanation

In order to understand how react native creates views in the background, you'll need to understand the fundamentals, and for that, I'd rather start from the ground up

1.The Yoga layout engine

Yoga is a cross-platform layout engine written in C which implements Flexbox through bindings to the native views (Java Android Views / Objective-C iOS UIKit).

All the layout calculations of the various views, texts and images in React-Native are done through yoga, this is basically the last step before our views get displayed on the screen

2. Shadow tree/Shadow nodes

When react-native sends the commands to render the layout, a group of shadow nodes are assembled to build shadow tree which represented the mutable native side of the layout (i.e: written in the corresponding native respective language, Java for Android and Objective-C for iOS) which is then translated to the actual views on screen (using Yoga).

3. ViewManager

The ViewManger is an interface that knows how to translate the View Types sent from the JavaScript into their native UI components. The ViewManager knows how to create a shadow node, a native view node and to update the views. In the React-Native framework, there are a lot of ViewManager that enable the usage of the native components. If for example, you'd someday like to create a new custom view and add it to react-native, that view will have to implement the ViewManager interface

4. UIManager

The UIManager is the final piece of the puzzle, or actually the first. The JavaScript JSX declarative commands are sent to the native as Imperative commands that tell React-Native how to layout the views, step by step iteratively. So as a first render, the UIManager will dispatch the command to create the necessary views and will continue to send the update diffs as the UI of the app changes over time.

So React-Native basically still uses Reactjs's ability to calculate The difference between the previous and the current rendering representation and dispatches the events to the UIManager accordingly

To know about the process a bit more in depth, I recommend the following presentation by Emil Sjölander from the React-Native EU 2017 Conference in Wroclaw