React JS Component Mounting: React is a library that values programming principles. One of them is the idea of components as elements. A component is a programmatic (declarative) way to render what you want in your application. But React doesn’t actually care about where or how you choose to render those elements. Whether it is JavaScript DOM or elsewhere.
React JS Component Mounting
This can sound surprising at first because React is known for being primarily a front end library. That is because React uses something known as render targets. That is, you determine how the results of a react’s render method will be displayed or passed on elsewhere. In other words, you can say that React is agnostic when it comes to the output of data or states stored within its components.
For example… you can output data from a component to file writing function. In other words, React’s rendering target is not limited just to UI elements, even though throughout most of this tutorial and react-style programming, in general, this is what you will be dealing with for the most part.
In the previous section, we’ve talked about how each component takes care of its own state. A state could be a boolean flag indicating whether a button is highlighted. Or whether a navigation menu option is selected. Now, if you’ve been paying attention this is where it all starts coming together. A react component is a fusion between its state and rendering method. We’re given programmatic control over the two most important functions of a UI element in one place.
What is mounting in React JS?
In React we are using a virtual representation of the DOM for performance reasons. By simply creating a component, no DOM elements will be even touched. This is great news but how could it be? This is because using native DOM would increase memory imprint of our application. However, with React’s virtual DOM, elements are created only when they are required to be used by the application.
React is an isomorphic framework. Its functionality can be mapped to an arbitrary output.Not just JSX-style HTML UI elements.The virtual DOM provided by the react library is exactly just virtual. It doesn’t physically exist within actual JavaScript DOM until it actually needs to be used by the application. Just think about it this way. The JavaScript DOM is a physical tree of HTML elements stored in memory. It is populated while the page is loading into your browser.
Usually, when a web page is loaded into the web application, each DOM branch represented by HTML element brackets loads up into the primary root DOM element regardless of how it will be used, or whether it will even be shown on the screen. The footer will be loaded into DOM, even if it is displayed at the end of the browser.
React, on the other hand, doesn’t even touch that DOM tree. As discussed in one of the precious gems, it adds or removes components from or to its own virtual DOM, which is stored completely in memory. An element becomes physically represented in the memory of the render target usually only when the component is purposely used within your application. It’s almost like copying and pasting virtual DOM to a render target, whatever it may be. In the case of web applications, it is a JavaScript DOM tree.
Virtual DOM Example
var component =React.createElement( ComponentDefinition );
At this moment component is an instance of the React type ComponentDefinition which I made up just for this example. In reality, it would correspond to a component like Login Screen, Navigation Menu or Button. And it would contain the standard component definition code we’ve already seen in earlier sections.
It is not yet physically existent anywhere in the primary JavaScript’s document (DOM) object. Aside from being a reacting node, it is nowhere else to be found. This is because as of yet it has no physical purpose in terms of being displayed in your application. But this is true only until the render method is executed on this component. Here, the container is just some is of a DIV or other HTML element:
Container Example
React.render(component, container);
The render method mounts this component to the DOM. The reason this process is referred to as mounting is similar to virtual hard drives. If you’ve ever mounted a virtual CD-ROM or hard drive on your computer, you know how it works. The hard drive doesn’t physically exist.
For the same reason, this is why this type of software is called a virtual hard drive. Or virtual CD-Rom. And this is why virtual drives have features like “mount this drive.” Likewise, this is the same principle behind virtual DOM to React. Until it is mounted, it cannot be operated upon. This is what makes React so much faster than regular DOM relations. And this is probably one of the top reasons for using React in the first place.
React stores a fast in-memory representation of the DOM. But this virtual DOM is not even associated with the JavaScript DOM. It exists side by side and renders into the actual DOM on the screen only when it becomes necessary. Usually, when the components representing an element is actually updated with new incoming data.
This mounting mechanism makes React to a versatile library. Because at its basic principle, React also doesn’t care whether the final result is rendered in the DOM or elsewhere. You can render React output into an XML document, treat it as custom object data, or return a JSON. It combines familiar programming principles and tries to be “everything for everyone.” This is what makes React an incredibly powerful tool for programming User Interfaces as well as inconsiderable around with custom software implementations.