Does React Native have a 'Virtual DOM'?

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.

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

I don't know if this is the answer to your question but I found this in the the official React docs:

> React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native.

So I would say that yes, it manages a very similar internal representation to the one used in React.js. Then I guess that it uses Javascript APIs to render native views just like the article you read suggests.

EDIT This post provided by Sebas in a comment is also interesting because a member of the React (and React Native) team says that:

> React Native shows that ReactJS has always been more about "zero DOM" than "virtual DOM" (contrary to popular belief).

It seems like the so-called 'React virtual DOM' is much closer to an internal structure/representation of the elements that can be mapped to various technologies than to a HTML DOM.

This article describes new React architecture called Fiber. It seems to be the correct answer about what's going on in React Native or at least what React Native will be trying to achieve in the nearest future.

> The DOM is just one of the rendering environments React can render to, > the other major targets being native iOS and Android views via React > Native. (This is why "virtual DOM" is a bit of a misnomer.) > > The reason it can support so many targets is because React is designed > so that reconciliation and rendering are separate phases. The > reconciler does the work of computing which parts of a tree have > changed; the renderer then uses that information to actually update > the rendered app. > > This separation means that React DOM and React Native can use their > own renderers while sharing the same reconciler, provided by React > core. > > Fiber reimplements the reconciler.

Here's an over-simplification: ReactJS outputs the DOM that can be rendered the browsers. As you already know, the virtual DOM helps ReactJS efficiently keeps track of the delta of what has changed. For React Native for iOS, ultimately it outputs UIKit code. Same thing with React Native for Android, but instead of outputting DOM or UI Kit, the output is created using Android SDKs. So virtual DOM is just an intermediate step. It can be considered as a combination of the internal data structure to hold the data that describes where to render the button and textbox, what happens when you tab the button, etc, and an efficient algorithm to keep track what has changed. The same code can be used for all platforms. Only the final step is different. Depending on the platform, it has code that generates the DOM, UIKit code, or whatever name Android UI lib is called.