DEV Community: Subham Dash

Event Flow: The Magic Behind Bubbling and Capturing! 🌟

Subham Dash — Sun, 17 Mar 2024 14:44:34 +0000

Ever wondered how your browser processes those clicks, scrolls, and hovers you make on a webpage? Let's uncover the magic of event flow, where the journey of an event begins!

🔍 Event Flow Basics:

Events in the DOM (Document Object Model) follow a fascinating journey through various elements. This journey involves two crucial phases: capturing and bubbling.

💫 Capturing Phase:

During the capturing phase, the browser starts from the outermost ancestor element of the target element and traverses down to the target element itself. It's like zooming in from the global scope to the specific element that triggered the event.

🚀 Bubbling Phase:

Conversely, the bubbling phase starts at the target element and then bubbles up through its ancestor elements until it reaches the topmost element in the DOM hierarchy. This phase mirrors the event's propagation back to the document root.

By default, all events you add with addEventListener are in the bubble phase.

Here's an example of how it works, which I'll explain below:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="style.css" />
    <title>Practice</title>
  </head>
  <body>
    <h1>Bubbling and Capturing phase</h1>

    <div>
      <button class="child">click me</button>
    </div>

    <script>
      const parent = document.querySelector("div");
      const child = document.querySelector(".child");

      parent.addEventListener("click", function () {
        console.log("clicked parent");
      });

      child.addEventListener("click", function () {
        console.log("clicked child");
      });
    </script>
  </body>
</html>

Output in the console:

clicked child
clicked parent

To reverse the order(Capture events first)

The click event of its parent elements must be triggered before the click of the nested element. This phase trickles down from the top of the DOM tree to the target element.

Whenever the third argument of addEventListener is set to true, event handlers are automatically triggered in the capturing phase.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="style.css" />
    <title>Practice</title>
  </head>
  <body>
    <h1>Bubbling and Capturing phase</h1>

    <div>
      <button class="child">click me</button>
    </div>

    <script>
      const parent = document.querySelector("div");
      const child = document.querySelector(".child");

      parent.addEventListener(
        "click",
        function () {
          console.log("clicked parent");
        },
        true
      );

      child.addEventListener("click", function () {
        console.log("clicked child");
      });
    </script>
  </body>
</html>

Output in the console:

clicked parent
clicked child

stopPropagation

As its name suggests, the Event.stopPropagation method stops propagation. Any other listener for the same type of event on some ancestor element will not trigger their event listener for the event.

👉 Event Bubbling vs. Event Capturing:

While both phases play a role in event propagation, developers often utilize event bubbling due to its intuitive nature. However, event capturing can be handy for specific use cases, such as intercepting events before they reach their target.

🛠️ Practical Application:

Imagine building a dynamic dropdown menu or a complex form with multiple interactive elements. Understanding event flow enables us to manage these interactions seamlessly, enhancing user experience and maintaining code maintainability.

🎉 Conclusion:

Event flow, with its captivating journey from capturing to bubbling, forms the backbone of interactive web development. Embrace this magic, and unlock endless possibilities in crafting delightful web experiences!

I have tried to explain all the details of the event flow that I know.

Thanks For Reading, Follow Me For More

WebSockets

Subham Dash — Fri, 15 Mar 2024 12:04:31 +0000

A WebSocket is a communication protocol that provides full-duplex communication channels over a single TCP connection. It enables a real-time, event-driven connection between a client and a server.

"Full duplex" refers to the capability of a communication system to transmit data in both directions simultaneously. In the context of a WebSocket connection, it means that both the client and the server can send and receive data at the same time without having to wait for each other to finish transmitting.

(Image Source: Internet)

Best React WebSocket libraries

Socket.IO: It is a widely used library that provides real-time bidirectional event-based communication between the browser and the server. It offers features like automatic reconnection, fallback options, and support for various transports, making it an excellent choice for building scalable and reliable applications. Socket.IO supports multiple programming languages, including JavaScript, Python, and Java.
SockJS is a JavaScript library that provides a WebSocket-like object in the browser, even if the server doesn't support WebSockets. It offers a fallback mechanism that uses alternative transport protocols, such as HTTP long-polling, allowing your application to work in environments where websockets are unavailable. SockJS can be used with various backends and programming languages, including Node.js, Java, and Python.
WS is a simple and lightweight WebSocket implementation for Node.js. It provides a straightforward API for creating WebSocket servers and clients, making it easy to integrate websockets into your Node.js applications. ws offers per-message compression, automatic reconnection, and customizable options for handling incoming and outgoing messages.

How WebSocket works in simple words

In the case of WebSocket there a handshake will happen between the client and the server and there server tells that I am going to share an HTTP upgrade request. What it meant by is, I am going to upgrade the connect to websocket. Then a connection will open which can help in having bidirectional requests. HTTP is going to be upgraded using method 101(used to change your network protocol)

Example

This is a real-time live comment section where all the live comments are broadcast. And in the demo project, I am using socket.io.

We will create a normal HTML file and run the script in the script tag, where we will call io().
- io(): This is a function provided by the Socket.IO library. It creates a WebSocket connection to the server.
- In the client, we listen to a 'chat message' event and when we receive a message then show it in the UI.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    <style>
      body {
        margin: 0;
        padding-bottom: 3rem;
        font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
          Helvetica, Arial, sans-serif;
      }
      #form {
        background: rgba(0, 0, 0, 0.15);
        padding: 0.25rem;
        position: fixed;
        bottom: 0;
        left: 0;
        right: 0;
        display: flex;
        height: 3rem;
        box-sizing: border-box;
        backdrop-filter: blur(10px);
      }
      #input {
        border: none;
        padding: 0 1rem;
        flex-grow: 1;
        border-radius: 2rem;
        margin: 0.25rem;
      }
      #input:focus {
        outline: none;
      }
      #form > button {
        background: #333;
        border: none;
        padding: 0 1rem;
        margin: 0.25rem;
        border-radius: 3px;
        outline: none;
        color: #fff;
      }
      #form > button:hover {
        cursor: pointer;
        background-color: #0f0e0e;
      }
      #messages {
        list-style-type: none;
        margin: 0;
        padding: 0;
      }
      #messages > li {
        padding: 0.5rem 1rem;
      }
      #messages > li:nth-child(odd) {
        background: #efefef;
      }
    </style>
    <script src="/socket.io/socket.io.js"></script>
  </head>
  <body>
    <h1>Subham's websocket app</h1>
    <ul id="messages"></ul>
    <div style="position: absolute; bottom: 5px">
      <body>
        <ul id="messages"></ul>
        <form id="form" action="">
          <input id="input" autocomplete="off" /><button>Send</button>
        </form>
      </body>
      <script>
        const socket = io();
        const form = document.getElementById("form");
        const input = document.getElementById("input");
        const message = document.querySelector("#messages");

        form.addEventListener("submit", (e) => {
          e.preventDefault();
          if (input.value) {
            socket.emit("chat message", input.value);
            input.value = "";
          }
        });

        socket.on("chat message", (msg) => {
          const item = document.createElement("li");
          item.textContent = msg;
          message.appendChild(item);
        });
      </script>
    </div>
  </body>
</html>

Note: I am adding the Backend code for better understanding.

Let us implement a simple Backend that will broadcast the messages/comments

const express = require("express");
const { createServer } = require("node:http");
const { join } = require("node:path");
const { Server } = require("socket.io");

const PORT = 3010;
const app = express();
const server = createServer(app);
// The Server class extends the functionality of the provided HTTP server to handle WebSocket connections alongside regular HTTP requests.
const io = new Server(server);

app.get("/", (req, res) => {
  res.sendFile(join(__dirname, "index.html"));
});

// This line listens for the 'connection' event emitted by clients when they establish a WebSocket connection to the server. When a client connects to the server, this event is triggered.
io.on("connection", (socket) => {
  console.log("Connection established");
  //  This line sets up an event listener on the socket object for the 'chat message' event. When the client sends a 'chat message' event to the server, this listener is triggered.
  socket.on("chat message", (msg) => {
    console.log("received message", msg);
    io.emit("chat message", msg);
  });

  socket.on("disconnect", () => {
    console.log("User disconnected!");
  });
});

server.listen(PORT, () => {
  console.log("server running at http://localhost:3010");
});

Here in the demo screenshot, I have opened 2 tabs and from 1st tab, I commented "Hi" and from another, I commented "hello"

Challenges to consider while implementing

Resource usage
Connection limits
Load balancing
Authentication
Firewall/Proxy
Scaling
Testing/Debugging
Resource cleanup
Error handling

Applications of WebSockets

Chat Applications
Live Feeds and Notifications
Online Gaming
Financial Trading Platforms
Real-Time Analytics and Monitoring
Live Streaming and Broadcasting

I have tried to explain all the details of SSE that I know.

Thanks For Reading, Follow Me For More

Server Sent Events(SSE)

Subham Dash — Wed, 06 Mar 2024 17:27:07 +0000

A server-sent event is when a web page automatically gets updates from a server. Traditionally, a web page has to send a request to the server to receive new data, then the server will send the response to the client. With server-sent events, a server can send new data to a web page at any time, by pushing messages to the web page.

If we are implementing SSE, we should keep the following two things in mind:

A long-lived unidirectional communication exists (the communication happens between the server and the client)
An HTTP connection only

Communication flow between Server and Client using Server Sent Events. (Image Source: PubNub)

An HTTP request has been made. As long as we do not explicitly close this connection by doing some actions, such as changing the tab, this request will never terminate or close.

Every time there is new data, the server passes it on a regular interval over the same HTTP network, which is open.

Implementation

Connection should be live
The format in which data comes is event-stream

Example

We will understand the working of Server-Sent Events using an example. Suppose, we have a stock price listing platform where our stock prices are to be updated continuously. Now for this, we only need a unidirectional connection i.e. server to client, where our server would send the new prices to our clients whenever they are updated on our server.

We will create a normal HTML file and run the script in the script tag, where we will call (/see) and render the latest stock prices whenever the server updates them.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>SSE Test App</title>
</head>
<body>
  <h1>In SSE App</h1>
  <section style="height: 100px; width: 300px; background-color: antiquewhite;">
  <ul style="list-style-type:disc">
    <li> Stock1 Price : <span id="first-element"></span></li>
    <li >Stock2 Price : <span id="second-element"></span></li>
  </ul>
  <div id="time"></div>

  </section>

  <script>
    const eventSource = new EventSource('/sse')
    eventSource.onmessage = (event)=>{
      const resObject = JSON.parse(event.data)
      const firstElement = document.getElementById('first-element')
      firstElement.innerText = `${resObject.stock1Rate}`
      const secondElement = document.getElementById('second-element')
      secondElement.innerText = `${resObject.stock2Rate}`
      const timeElement = document.getElementById('time')
      timeElement.innerText = `${resObject.currentTime}`
    }
  </script>
</body>
</html>

Note: I am adding the Backend code for better understanding.

Let us implement a simple Backend API to serve us stock prices at an interval of 5 seconds.

const express = require("express");
const {join} = require('node:path')

const PORT = 3010
const app = express()

app.use(express.static("public"));

app.get("/sse",(req, res)=>{
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Connection','keep-live');
  res.setHeader('Cache-Control', 'no-cache');

  const intervalId = setInterval(() => {
    const stock1Rate = Math.floor(Math.random() * 30000);
    const stock2Rate = Math.floor(Math.random() * 40000);
    const currentTime = new Date().toLocaleTimeString()
    res.write(`data: ${JSON.stringify({currentTime,stock1Rate, stock2Rate})} \n\n`)
  }, 5000);

  req.on('close', ()=>{
    clearInterval(intervalId)
  })

})

app.get("/", (req, res) => {
  res.sendFile(join(__filename, "/index.html"));
});

app.listen(PORT,()=>{
  console.log(`App is connected to ${PORT}`)
})

In the UI the stock prices will change after each 5sec -

You can see how the response is received in the browser-

Challenges that we may face while implementing

Browser compatibility
Connection limit
Connection timeout
Background tab behavior
Resource utilization
Load balancer
Sticky connection
Proxy/Firewall

I have tried to explain all the details of SSE that I know.

Thanks For Reading, Follow Me For More

A description of how browser rendering works

Subham Dash — Wed, 23 Nov 2022 13:26:48 +0000

The Browser render Story (3 Part Series)

The process of rendering HTML

The process of rendering CSS

The Process of rendering JS

Overview
From raw bytes of HTML to DOM
From raw bytes of CSS to CSSOM
Laying out the render tree
The Process of rendering JS

This article explains how your browser converts HTML, CSS, and JavaScript into a working website that you can interact with.

Let’s get started.

Overview

A web browser is a piece of software that loads files from a remote server (or perhaps a local disk) and displays them to you allowing for user interaction.

However, within a browser, there’s a piece of software that figures out what to display to you based on the files it receives. This is called the browser engine.

The browser engine is a core software component of every major browser, and different browser manufacturers call their engines by different names. The browser engine for Firefox is called Gecko, and Chrome’s is called Blink, which happens to be a fork of WebKit.

1. The process of rendering HTML

When you write some HTML, CSS, and JS, and attempt to open the HTML file in your browser, the browser reads the raw bytes of HTML from your hard disk (or network).

Note- The browser reads the raw bytes of data, and not the actual characters of code you have written.

The browser receives the bytes of data, but it can’t really do anything with it; the raw bytes of data must be converted to a form it understands. This is the first step.

(credit: internet)

From raw bytes of HTML to DOM

First, the raw bytes of data are converted into characters. This conversion is done based on the character encoding of the HTML file.

Characters are great, but they aren’t the final result. These characters are further parsed into something called tokens.

Without this tokenization process, the bunch of characters will just result in a bunch of meaningless text, i.e., HTML code — and that doesn’t produce an actual website.

When you save a file with the .html extension, you signal to the browser engine to interpret the file as an HTML document. The way the browser interprets this file is by first parsing it. In the parsing process, and particularly during tokenization, every start and end HTML tag in the file is accounted for.

The parser understands each string in angle brackets (e.g. - <html>, <p>) and understands the set of rules that apply to each of them. For example, a token that represents an anchor tag will have different properties from one that represents a paragraph token.

Conceptually, you may see a token as some sort of data structure that contains information about a certain HTML tag. Essentially, an HTML file is broken down into small units of parsing called tokens. This is how the browser begins to understand what you’ve written.

Tokens are great, but they are also not our final result. After the tokenization is done, the tokens are then converted into nodes. You may think of nodes as distinct objects with specific properties. In fact, a better way to explain this is to see a node as a separate entity within the document object tree.
Nodes are great, but they still aren’t the final results.

Now, here’s the final bit. Upon creating these nodes, the nodes are then linked in a tree data structure known as the DOM. The DOM establishes the parent-child relationships, adjacent sibling relationships, etc. The relationship between every node is established in this DOM object.

We don’t open the CSS or JS file in the browser to view a webpage. We open the HTML file, most times in the form index.html. This is exactly why you do so: the browser must go through transforming the raw bytes of HTML data into the DOM before anything can happen.

(credit: internet)

Depending on how large the HTML file is, the DOM construction process may take some time. No matter how small, it does take some time, regardless of the file size.

2. The process of rendering CSS

A typical HTML file with some CSS will have the stylesheet linked as shown below:

<!DOCTYPE html>
<html lang="en">

<head>
  <link rel="stylesheet" href="style.css">
  <title>Document</title>
</head>

<body>

</body>

</html>

While the browser receives the raw bytes of data and kicks off the DOM construction process, it will also make a request to fetch the main.css stylesheet linked. As soon the browser begins to parse the HTML, upon finding a link tag to a CSS file, it simultaneously makes a request to fetch that.

From raw bytes of CSS to CSSOM

As you can see, a similar process occurs when the browser receives raw CSS bytes.

This is achieved by converting raw bytes of data into characters, then tokenizing them. In addition, nodes are formed, and then a tree structure is formed.

DOM stands for Document Object Model. Most people know what it is. In the same way, CSS has a tree structure called CSS Object Model (CSSOM).

Both HTML and CSS cannot be accessed by the browser by raw bytes. This has to be converted to a form it recognizes — and that happens to be these tree structures.

CSS has something called the "cascade". The cascade is how the browser determines what styles are applied to an element. Because styles affecting an element may come from a parent element (i.e., via inheritance), or have been set on the element themselves, the CSSOM tree structure becomes important.

All well and good. The browser has the DOM and CSSOM objects. Can we have something rendered to the screen now?

The render tree

What we have right now are two independent tree structures that don’t seem to have a common goal.

The DOM and CSSOM tree structures are two independent structures. The DOM contains all the information about the page’s HTML element’s relationships, while the CSSOM contains information on how the elements are styled.

OK, the browser now combines the DOM and CSSOM trees into something called a render tree.

(credit: internet)
The render tree contains information on all visible DOM content on the page and all the required CSSOM information for the different nodes. Note that if an element has been hidden by CSS (e.g., by using display; none), the node will not be represented in the render tree.

The hidden element will be present in the DOM but not the render tree. This is because the render tree combines information from both the DOM and the CSSOM, so it knows not to include a hidden element in the tree.

With the render tree constructed, the browser moves on to the next step: layout!

Laying out the render tree

Well, first, the browser has to calculate the exact size and position of each object on the page. It’s like passing on the content and style information of all elements to be rendered on the page to a talented mathematician. This mathematician then figures out the exact position.

This layout step (which you’ll sometimes hear called the “reflow” step) takes into consideration the content and style received from the DOM and CSSOM and does all the necessary layout computing.

With the information about the exact positions of each element now computed, all that is left is to “paint” the elements to the screen. The browser now “paints” the individual node to the screen. Finally, the elements are now rendered to the screen!

3.The Process of rendering JS

You can remove and add elements from the DOM tree, and you may modify the CSSOM properties of an element via JavaScript, and this JS code written in <script> tag.

Well, one of the most important things to remember is that whenever the browser encounters a script tag, the DOM construction is paused! The entire DOM construction process is halted until the script finishes executing.

This is because JavaScript can alter both the DOM and CSSOM. Because the browser isn’t sure what this particular JavaScript will do, it takes precautions by halting the entire DOM construction altogether.

Best practice is always to put script tag right to the end, just before the closing of body tag. So that the UI will be shown to the user as a first priority.

<head>
    <title>Demo</title>
    <link rel="stylesheet" href="style.css">
</head>

<body>
    <p id="paragraph">How Browser Rendering Works</p>
    <div><img src="https://xyz.jpg">
    <script>
        let header = document.getElementById("paragraph");

        console.log("paragraph is: ", paragraph);
    </script>
</body>

</html>

Here in the above scenario you'll get the proper output in the cosole as- paragraph is: <p id="paragraph">How Browser Rendering Works</p>.

But if you put script tag in the head or at the starting of the body then you will get paragraph is: null

Why? Pretty simple.

While the HTML parser was in the process of constructing the DOM, a script tag was found. At this time, the body tag and all its content had not been parsed. The DOM construction is halted until the script’s execution is complete.

By the time the script attempted to access a DOM node with an id of header, it didn’t exist because the DOM had not finished parsing the document!

So, what happens when the parser encounters a script tag but the CSSOM isn’t ready yet?

Well, the answer turns out to be simple: the Javascript execution will be halted until the CSSOM is ready.

The async attribute

By default, every script is a parser blocker! The DOM construction will always be halted.

There’s a way to change this default behavior though.

If you add the async keyword to the script tag, the DOM construction will not be halted. The DOM construction will be continued, and the script will be executed when it is done downloading and ready.

Here’s an example:

<head>
    <title>Demo</title>
    <link rel="stylesheet" href="style.css">
    <script src="index.js" async></script>
</head>

<body>
    <p id="paragraph">How Browser Rendering Works</p>
    <div><img src="https://xyz.jpg">
</body>

</html>

DEV Community: Subham Dash

Event Flow: The Magic Behind Bubbling and Capturing! 🌟

🔍 Event Flow Basics:

💫 Capturing Phase:

🚀 Bubbling Phase:

Output in the console:

To reverse the order(Capture events first)

Output in the console:

stopPropagation

👉 Event Bubbling vs. Event Capturing:

🛠️ Practical Application:

🎉 Conclusion:

WebSockets

Best React WebSocket libraries

How WebSocket works in simple words

Example

Challenges to consider while implementing

Applications of WebSockets

Server Sent Events(SSE)

Communication flow between Server and Client using Server Sent Events. (Image Source: PubNub)

Implementation

Example

Challenges that we may face while implementing

A description of how browser rendering works

Table of contents

Overview

1. The process of rendering HTML

From raw bytes of HTML to DOM

2. The process of rendering CSS

From raw bytes of CSS to CSSOM

The render tree

Laying out the render tree

3.The Process of rendering JS

The async attribute