DEV Community: Aiman Jaffer

React Internals: How React works

Aiman Jaffer — Mon, 18 Oct 2021 18:25:35 +0000

This article will attempt to formalize my understanding of how the React library work internally to allow us to create complex web-applications. Without any further ado, let's dive right into it.

HTML and the DOM

Let's start with two terms that you will encounter a lot in web development: HTML and DOM. HTML stands for Hypertext Markup Language. A web-page is simply a document written in HTML.

DOM stands for Document Object Model. The DOM is the representation of the web-page that is understood by the web-browser. The DOM is represented as a tree of HTML tags. (In a Tree data structure, each node can have zero or more child-nodes. The child-nodes belonging to the same parent are known as siblings and nodes without children are known as leaf nodes.)

The DOM provides APIs through which we can make changes to the web-page. For example using methods like document.getElementById etc.

Components

React is a Component-based library. Components are a layer of abstraction in that they allow us to describe the UI we wish to generate while leaving the implementation details to React.
React Components can be created in two ways:
1) Using Classes
2) Using Functions

While using Class-based components we use the render() method to define the JSX that should be displayed on the browser whereas while using Functional components we directly return the JSX that should be rendered as the result of the function.

JSX and React.createElement

JSX allows you to write HTML code directly inside JavaScript functions. It is syntactic sugar for the method React.createElement().

JSX is converted to regular JavaScript via a transpiler known as Babel (using the preset babel/preset-react).

Let's examine this in detail using an example:
This is a simple Component that I already had from a hobby project:

export default function PlaylistDetail(props){
    return (
        <div>
        <p>Playlist Name</p>
        <p>Created by</p>
        <div>Track List</div>
        </div>
    );
}

Compiling this code using Babel produces the following output:

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.default = PlaylistDetail;

function PlaylistDetail(props) {
  return /*#__PURE__*/ React.createElement(
    "div",
    null,
    /*#__PURE__*/ React.createElement("p", null, "Playlist Name"),
    /*#__PURE__*/ React.createElement("p", null, "Created by"),
    /*#__PURE__*/ React.createElement("div", null, "Track List")
  );
}

From this, we conclude that JSX tags are ultimately converted to calls to the React.createElement() method. Now you may be thinking: That's great! But why should I care? We'll get to that in a bit. Hang tight, all of this will make a lot more sense in a bit, I promise. We just need to understand what an Element is in React.

Elements and Component Instances

An Element in React is a simple JavaScript object that describes the instance of a component. Think of Components as being general and Component instances as specific (i.e. A Component with specific props and state). Whenever the props and state of a Component change it results in a different instance of the Component.

The Element object representing the instance of the PlaylistDetail Component seen previously is shown below:

{
  $$typeof: Symbol(react.element),
  key: null,
  props: {
    children: [
      {
        $$typeof: Symbol(react.element),
        key: null,
        props: {
          children: "Playlist Name"
        },
        ref: null,
        type: "p"
      },
      {
        $$typeof: Symbol(react.element),
        key: null,
        props: {
          children: "Created by"
        },
        ref: null,
        type: "p"
      },
      {
        $$typeof: Symbol(react.element),
        key: null,
        props: {
          children: "Track List"
        },
        ref: null,
        type: "div"
      }
    ]
  },
  ref: null,
  type: "div"
}

The $$typeof field is used to prevent Cross site scripting Attacks (XSS) since it should always contain a Symbol which prevents the JavaScript object from being parsed from plain JSON objects.

The key field is used to optimize performance by allowing elements generated from a list to be uniquely identified.

The props field is an object containing all the props that are passed to the Component. The props field also stores children which is an array containing the children of the current element.

The type field refers to the type of the object either a native HTML tag or a Component type. In this example the type is a native HTML div.

The ref field stores a reference to the actual DOM node. (This can be utilized via the useRef hook).

Thus, we see that React components (and their child components) can be represented as objects (with nested objects) similar to the way the web-page is itself represented via the tree structure of the DOM. Hence this representation of React components as a tree of objects is known as the Virtual DOM.

Why bother?

The reason React goes through this cumbersome process of maintaining object representations of Components is simple: Performance. It's computationally much cheaper to create and manipulate JavaScript objects than it is to manipulate the DOM.

This allows React to consolidate all the changes that need to be made in a render cycle and perform one bulk update to the DOM instead of performing many smaller changes.

Reconciliation

Now, let's take a look at how React determines when a Component needs to be re-rendered and what exactly has changed since the previous render cycle. This information is required in order to prevent unnecessary DOM updates. (i.e. updating DOM nodes that have not been changed since the previous render)

The process of maintaining the tree of Elements whenever a Component's props or state change is known as Reconciliation. React does this by maintaining the state of the Element tree from the previous render and comparing it to the new Element tree using an diffing algorithm.

The problem of comparing the previous tree (or graph) with the new tree is known in Computer Science as the Graph Edit Distance Problem.

Theoretically, this problem falls under a class of problems known as NP-hard (non-deterministic polynomial-time) but there are approximation solutions to this problem in O(n^3). React's diffing algorithm uses certain optimizations that further reduce the runtime to O(n). (n is number of nodes in the tree).

Optimizations, you say?

The optimizations React uses to achieve this performance boost are:

If an element's type field has changed, then React re-creates the entire subtree (for this particular element and it's children).
React uses the key field to uniquely identify elements generated dynamically from a list in order to prevent recreating the entire list when list operations are performed (E.g. when elements added or deleted, or list is reversed etc.). React simply makes the relevant changes directly in the DOM.
When attributes of native DOM elements are changed but the element type remains the same then only the attributes that have changed are updated (instead of re-creating the entire DOM Node).

Rendering vs Reconciliation

The process of Reconciliation (that we looked at in the previous section) determines what changes need to be made to the DOM.

The process of actually making these changes is known as Rendering. There is a separation of concerns between the packages responsible for Reconciliation and Rendering.

The react package is only concerned wit Reconciliation.
The react-dom package is concerned with actually performing the rendering on the browser. It does this via the ReactDOM.render() method.

This separation of concerns allows react-native to replace react-dom while rendering to mobile apps.

TO BE CONTINUED

How does Rendering work? Fibers

How Rendering previously worked with React Stack? (before v16) Stack vs LinkedList

Lessons Learnt: Building a real-time direct messaging web app

Aiman Jaffer — Mon, 04 Oct 2021 20:46:01 +0000

I recently worked on building two personal projects that involve real-time communication between users. The first was a direct messaging application and the second was an online chess application. These are my key takeaways and lessons learnt from the process of building these two applications. Let's begin by taking a look at the architecture of these applications individually.

Application Overview

This was the first real-time web application that I was involved in building. I had recently learnt React.js and I was eager for an opportunity to put my theoretical knowledge to test and to prove to myself that I was in fact capable of developing responsive React applications.

I had chosen the MERN stack for this project since since it seemed like the go-to option to use a Javascript backend (Node.js + Express) alongside a React frontend. I had also never used a NoSQL database before, all my database experience was with relational databases so I was keen to give it a shot with nothing at stake but my self-esteem.

I knew that one of the most important things for a good user experience when using any messenger application is that messages should automatically show up on the conversation screen without the user having to refresh their browser window each time. I did a bit of Googling and decided that this would be a good use case for WebSockets.

User Stories

I decided that the Minimum Viable Product for this build should incorporate at least the following user stories:
1) Users should be able to sign-up using a username + password.
2) Users should be able to login using their credentials.
3) After successful login, Users should see a list of their ongoing conversations on the left pane.
3) Users should be able to start a new conversation using the "New Chat" button.
4) On clicking a conversation summary, the entire conversation should load on the right pane.
5) Users should be able to receive notifications when they receive a new message.
6) Users should be able to send messages. (I'll admit, this one was not that hard to think of)

I estimated that it would take about a week to complete if I was able to dedicate at least 2-3 hours per night. Furthermore, I wasn't too concerned about designing a beautiful User Interface (this was my first mistake) so I decided that Bootstrap was good enough for the task at hand. If I could do it all over again I would undoubtedly use TailwindCSS since their utility first approach (as opposed to Bootstrap's component first approach) leads to much more unique looking webpages. It's relatively trivial to instantly know when a web-app uses Bootstrap because all of them are practically identical, which is not the case with web-apps that use utility-based frameworks like Tailwind.

UI Components

The next step were to determine the UI components that I would need. These were the components that I ultimately decided on.

LoginComponent: Form where the User submits their username.
HomeComponent: Parent Component for all these components listed below.
ConversationSummaryList: Displayed after successful login, shows all the conversations the user has had.
ConversationSummary: Displays Conversation Name, Last Message. When clicked loads the respective Conversation component in the right pane
NewConversation: Button that when clicked loads ContactList
ContactList: List that displays all the user's contacts, each contact should be clickable to start a new conversation
Conversation: Left side pane displayed after user clicks on a conversation summary. Shows entire conversation.
UserProfile: Displays User's username, fullname, lastSeen / online status.
MessageList: All the messages in the conversation.
Message: Each individual message, displayed either on the right or left side of the window depending on whether it was sent or recieved.
AddMessage: Chatbox where the user types the message and clicks send / Enter button to send the message.

The design of the database collection would closely overlap with some of the components that are displayed on the UI i.e. Conversation, Message, ConversationSummary and an additional collection called Users (to handle authentication/authorization)

The Node.js backend consisted of APIs handler functions that would be required to perform basic CRUD functionality as well as user sign-up and login.

Once the development of the UI components, API handlers and the end-to-end integration between Client, Server and Database was complete. The only thing remaining was to implement real-time updates using WebSockets.

WebSockets and Azure App Service

Initially I had the WebSocket server code in the same Node.js application as the Webserver (although using different ports) this worked fine on my local environment during development but I soon learned when I tried deploying my app to Azure that I was unable to make calls to my WebSocket server since only port 80 and 443 are exposed by Azure App Service and these were used by the Express webserver. Thus, I ended up having to move all the WebSocket server code into a separate Node.js application so that it could run on the default ports.

Another key takeaway from this experience was that deploying the WebSocket server app to Azure App Service is a bit of an hassle to say the least.

For starters, at the time of this writing the Free Tier for Azure App Service on Linux does not support WebSocket connections. The Free Tier for Windows supports only up to 5 concurrent connections following which any client that tries to connect is greeted with a HTTP 503 error. The next App Service plan (Shared Tier) allows up to 35 concurrent connections.

Furthermore, apps deployed to Azure App service in the Free and Shared tiers have restrictions to the amount of CPU time they are allocated per day (60 and 240 mins respectively). Apps are deallocated from memory if they do not receive incoming requests and are brought back when required which leads to delays (known as cold starts) and an overall terrible user experience.

Node.js applications that are deployed on Azure App Service also sometimes face issues with WebSocket connections due to the way the handoff occurs between IIS and Node.js via iisnode. The web.config file plays an essential role in this and one must ensure that it is present and has the following configuration <webSocket enabled="false" />

I also faced similar issues for another application that I was developing that used Socket.IO instead of raw Websockets and ultimately concluded that it's simply not worth the hassle of using Azure App Service for this use case and found that Heroku was a much simpler and better option.

Handling Authentication

I was also handling the user sign-up and authentication logic myself in the server code and storing the credentials in users collection in the database (with hashed passwords). In hindsight I would not recommend this approach since this is not a secure way of going about it. I would absolutely recommend using Firebase for authentication instead due to the relative ease of integration and the improved security that comes with using OAuth / OpenIDConnect based authentication with an identity provider such as Google.

Next.js vs create-react-app

Another key lesson learnt was that it would have been much more efficient to have used Next.js instead of create-react-app while developing this application since Next.js allows backend code to be written in the application's /pages/api directory. The pages that are placed in this directory are run as Serverless functions once the Next.js app is deployed on Vercel thereby eliminating the need for a backend server hosted on a separate cloud instance (in this case Azure App Service). Another point to remember is that Serverless functions are essentially stateless by nature therefore if your backend needs to maintain stateful sessions or anything of that nature then going the Serverless route is not recommended.

All the code for this project can be found here

JavaScript Asynchronous Patterns and Closures

Aiman Jaffer — Wed, 22 Sep 2021 17:28:35 +0000

It can be daunting to make the transition to frontend web development even for someone who has prior programming experience with strongly-typed or object-oriented languages such as Java. JavaScript has a plethora of quirks that make it a very unique language to say the least, but it is the predominant language of the internet and mastering it is crucial to success as a web developer. These were some of the JavaScript concepts that baffled me when I began (some still do) but I hope this post will help you gain a better understanding of some of these key concepts that you may encounter in the wild.

Asynchronous execution of code

JavaScript is a single-threaded language, this means that at any point during a program's execution there can be a maximum of one statement that is being executed which is followed by the next statement and so on. This works fine for statements where the bulk of work to be performed is handled by the CPU (aka CPU-intensive tasks). The problem occurs when a program involves code that performs I/O-intensive tasks (such as network calls, filesystem read/write operations etc.) and is followed by code that performs relatively quicker CPU-bound tasks that don't necessarily rely on the output of these I/O-intensive tasks but are forced to wait for them to finish before they can begin execution (due to the single-threaded nature of JavaScript). For example:

const fs = require('fs');  
const filepath = 'text.txt';
const data = fs.readFileSync(filepath, {encoding: 'utf8'});
let sum  = 3 + 5;
console.log(sum);

In this example the statements involving calculating and logging the sum of 3 and 5 to the console must wait for the execution of all preceding code even though it is not dependent on the code that precedes it. This is an example of blocking I/O. This situation can be a significant bottleneck in the execution of a program and can lead to a unpleasant experience for the end-user of the program. Fortunately, there are a lot of ways to deal with this situation that are collectively known as asynchronous programming and when dealing with I/O operations specifically this is known as non-blocking I/O.
The 5 concepts we frequently encounter while implementing Asynchronous programming in JavaScript are:

Callbacks
Timeout functions
Promises
Async/Await
Observables (This one is specific to RxJs)

Callbacks

To understand callbacks in JavaScript we must first be familiar with the underlying principle that is: functions are first-class citizens in JavaScript. This means that functions are just like any other JavaScript objects, in that they can be assigned to variables, passed as parameters to other functions and can be returned from other functions (Higher Order Functions). This feature of JavaScript is crucial in order to implement callbacks as we shall see in the following example:

//Synchronous Execution example:
function doSomethingWithDataSync (data) {
//...do some I/O intensive task which returns result
return result;
}

let result = doSomethingWithDataSync("Hello");
console.log(result);
let y = 3 + 5;
console.log(y);

The same task can be performed using callbacks asynchronously as follows:

//Asynchronous Execution example:
function doSomethingWithDataAsync (data, callback){
//...do some I/O intensive task which returns result
if(error)
callback(error)
else
callback(null, result)
}

doSomethingWithDataAsync("Hello", function(error, data){
if(error)
console.log("Error occured");
else
console.log(data);
});
let y = 3 + 5;
console.log(y);

In this example we pass a function that takes two arguments error, data as parameters to the function doSomethingWithDataAsync. Once the execution of the I/O intensive statement is completed, the callback function is called in one of two ways depending on whether an error occurred or the task executed successfully. In this example execution of statements let y = 3 + 5; and console.log(y); are not waiting for the execution of function doSomethingWithDataAsync and the callback function to complete. We'll now learn about how this callback is moved off the call stack in order to be processed at a later point in time.

Timeout functions

Functions such as setTimeout and setInterval are perhaps the oldest way of executing code asynchronously in JavaScript. The function setTimeout takes two parameters: the first is a callback function which contains some code that should be executed and the second is a minimum time (in milliseconds) to wait before the callback function is executed. Note that this is the minimum time and not a guarantee that the callback function will be executed immediately when this timer expires. To understand how this allows JavaScript to execute asynchronous code we must first familiarize ourselves with how the browser executes JavaScript via the Stack, CallbackQueue, Web APIs and the Event Loop.

setTimeout and setInterval belong to a category of functions that are collectively known as Web APIs. These functions are not part of the JavaScript language themselves but are APIs exposed by the browser in order to aid developers.

The Call Stack (or simple the Stack) is a LIFO (last-in first-out) data structure used by browers to determine the execution context of a particular piece of code. Whenever a function is called it is add to the top of the stack and when the function completes it is removed from the stack. Thus the function at the top of the stack is always the currently executing function.

The Event Queue is a data structure used by the browser to store functions that are waiting to be executed once the stack is empty.

The Event Loop is the browser construct that checks whether the stack is empty and moves the function in the front of the Queue to the Call Stack.

Now that we know what each of these individual pieces are, let's see how they work together in the following example:

console.log("Before setTimeout callback function");
setTimeout(()=>{
console.log("Inside setTimeout callback function");
},1000);
console.log("After setTimeout callback function");

The output of this code snippet should be as follows:

Before setTimeout callback function
After setTimeout callback function
Inside setTimeout callback function

With a gap of at least one second between when the second and third statements are displayed.

Let's take a look at the individual steps that allow this behavior to occur:
(We assume that before we begin both the Call Stack and Event Queue are empty)

console.log("Before...") is the first statement that should be executed hence it is added to the stack. The message is displayed on the console and then the function is removed from the stack.
setTimeout is called with a callback function and a minimum wait time of 1 second.
setTimeout is added to the top of the stack and since it is a Web API it is immediately removed from the top of the stack.
The browser registers the timer and the associated callback function and begins the timer.
console.log("After...") is the next statement that should be executed hence it is added to the stack. The message is displayed on the console and then the function is removed from the stack.
Once the timer expires after the specified duration of time, the callback function is added to the Event Queue.
The Event Loop then checks whether the stack is empty and then moves the callback function (which is currently at the front of the Event Queue) to the stack for execution.
The callback function executes, the message is logged to the console. 8.The callback function is removed from the stack.

Promises

One of the issues observed while programming utilizing callbacks is that code readability suffers, especially when dealing with nested callback functions. Promises offer an alternate syntax that significantly improves code readability through the use of operation chaining (as opposed to nesting). A Promise represents the eventual result of an asynchronous operation and it's associated value. At any given time, a promise can be in one of 3 states:

Pending
Fulfilled
Rejected

We can deal with a promise that is in the fullfilled state via the .then(onFulfillment) method and perform error handling on a promise that is rejected via the .catch(onRejection) method. While chaining multiple promises all errors can be handled by a single .catch() placed at the end of the chain. An alternative to this is to specify both the onFulfillment and onRejection callbacks as arguments to .then() as .then(onFulfillment, onRejection). Internally a promise is fulfilled via the static method Promise.resolve(valueForSuccess) and rejected via the static method Promise.reject(valueForFailure).

Async/Await

Async/Await allows developers to write asynchronous code that very in style closely resembles synchronous code thus enhancing code readability even further than promise-style asynchronous code. Functions that contain asynchronous operations are marked with the async keyword and individual operations that are performed asynchronously are marked with the await keyword. Use of async await allows developers to use regular try catch blocks to perform error handling rather than .then() and .catch(). Also, Async functions are guaranteed to return Promises even if they are not explicitly created.

Observables

Observables are a technique for handling the execution of asynchronous tasks in the Angular framework through the use of RxJs library. Observables support multiple values as opposed to Promises that resolve to a single value. This pattern involves two actors. A Publisher that creates an Observable and provides a subscriber function. Any number of Consumers that call the .subscribe() method on the observable. The Consumer then receives new data via the Observable until the function completes execution or until they unsubscribe. The .subscribe() method takes three functions as parameters: next, error, complete. The first parameter is mandatory whereas the other two are optional. The next function is executed when the publisher publishes a new value, the error function is executed when the publisher sends an error notification and the complete function is executed when execution of the observable's subscriber function is complete.

Closures & Functions as First class Citizens

A closure in JavaScript is simply the combination of a function and the variables that it has access to when it was created. Let's understand this with and example:

function outerFunc(){
var playerName = "Michael Jordan";
function innerFunction(){
console.log("Player is: ", playerName);
} 
innerFunction();
}
outerFunc();

The output of this code is Player is: Michael Jordan, pretty straightforward so far right? Now let's see what happens when we return the innerFunction from the outerFunction instead of calling it directly (We are allowed to do this because in JavaScript functions are objects). For Example:

function outerFunc(){
var playerName = "Michael Jordan";
function innerFunction(){
console.log("Player is: ", playerName);
} 
return innerFunction;
}
var getPlayerName = outerFunc();
getPlayerName();

What do you expect will happen?

You might be inclined to think that since the inner function is now being called from a different context than that in which it was initially created inside it would not have access to the playerName variable. Go ahead try executing this code and see what happens for yourself.

You may be surprised to find that the output remains unchanged from the previous example. This is because functions in JavaScript are Closures, this means that functions once created always have access to the variables in the lexical scope in which they were defined.

Hope this was helpful !!
Links to useful resources below: