Forem: Anshuman Mahato

Inside JavaScript Runtime Environment

Anshuman Mahato — Wed, 30 Jul 2025 14:32:51 +0000

Hey there! Welcome to another article in this series where we discuss the core fundamental concepts of this awesome yet messy language, JavaScript. In the previous article, we discussed how JavaScript executes code. We learned about the JavaScript Engine, its components, JavaScript code compilation, Execution Contexts, and the flow of JavaScript code execution. And we had some pizza too. If you missed it, check it out here.

Well, it was all about the execution of synchronous code. Then what about asynchronous code? - You may ask. Worry not, because that's what we will explore in this article. In the first article of this series, I briefly mentioned the Runtime Environment. Let's begin from there and dive deeper.

The JavaScript Runtime Environment

A JavaScript Runtime Environment is the environment that enables the execution of JavaScript Code.

Wait what? Ain't that the Engine?

Hold up, let me clear this. The JavaScript Engine executes the code. The JavaScript Runtime Environment is what enables the Engine to do so. It defines the functionality that JavaScript can perform beyond just basic computation.

In the last article, I compared the JavaScript Engine to a cooking counter, remember? Now, can you have a cooking counter without a kitchen? No! It can be a home kitchen, a restaurant kitchen or maybe just a food truck. But there has to be a kitchen. The JavaScript Runtime Environment is that kitchen. The Engine is a part of the runtime environment. Yes, it is what executes the code. But, it is the Runtime Environment that facilitates, orchestrates and manages the process of execution.

Apart from the JavaScript Engine, the following are the other components of a JavaScript Runtime Environment -

APIs and Libraries
Task Queues
Event Loop

Let's go through all of these one at a time.

APIs and Libraries

These are pre-built functions and objects giving JavaScript access to system capabilities and external services, defining JavaScript's capabilities and functionalities for that Runtime Environment. Essentially, these are the tools and utilities that determine what JavaScript can do within that environment. So, will the capabilities of JavaScript differ from Runtime to Runtime, even if they use the same JavaScript Engine?

Well, Yeah! Think of the APIs like the utensils and facilities in a kitchen. Depending on the utensils, what you can cook will differ from one kitchen to another, even if they have the same cooking counter. The things you can do in a Bakery's kitchen will not be the same as those of an Asian Restaurant's kitchen. Come on! You can't be cooking Egg Fried Rice in a Bakery (unless you want to piss off Uncle Rogers 👀).

In a browser, for instance, you can manipulate web pages using DOM APIs, but you cannot access your computer's files directly. Switch to Node JS, and suddenly, you can interact with your operating system, but DOM manipulation is off-limits. Internally, both of these environments use the same Google V8 JavaScript Engine. The browser provides various Web APIs, including the DOM API, Timers API, History API, and Navigation API, among others. Node JS has C++ bindings for OS-level access and the Thread Pool. The JavaScript Engine does not inherently perform these by itself.

Whenever the JavaScript Engine encounters any tasks accessing these API's, such as a timeout or an AJAX call, it passes them to the Runtime Environment. Now, if these tasks are synchronous, the Engine will block the code execution and wait for the Runtime Environment to return. For asynchronous calls, the Engine does not wait. It passes them to the Runtime Environment and continues executing the code further. It's like baking a cake. You prepare the batter and place it in the oven to bake. And while the cake is in the oven, you prepare the frosting in the meantime.

Okay, but then, what happens once the Runtime Environment finishes these tasks? Well, this is how it goes. When the Engine makes an asynchronous API call to the Runtime Environment, it also registers a Callback Function with the call. The direction for the Runtime Environment is that upon the "event" of completion of the task, call for the execution of the registered function.

setTimeout(()=> alert("Timeout Baby"),5000);

Take a look at the call for setting up a timeout after 5 seconds. The first argument is the callback function to execute whenever someone clicks the button. When the Engine encounters this statement, it does not wait for the timeout to happen. It offloads this task to the Runtime Environment and goes to the following statement. Now, whenever this timer runs out, the Runtime Environment queues the callback function for execution.

And how are these queued-up functions tracked and executed? Well, that's where the Task Queues and the Event Loop come into play.

Task Queues and the Event Loop

Task Queues are data structures that keep track of callback functions that are up for execution. But, before moving ahead with this, know that asynchronous APIs generally fall into two categories: Callback-based APIs and Promise-based APIs. The key difference is that Callback-based APIs require you to pass the callback function directly as an argument. In contrast, the Promise-based APIs return a Promise object that you can attach callbacks to using .then() or handle with async/await. Don't worry if you have no idea about Promises. We don't need to understand them in depth at present. For now, think of it like getting a payment from a client. You can either give them your payment details and the directions to make the payment (Callback), or they can write you a check (Promise) that you can cash out yourself.

But if we don't need to know them just yet, then why am I telling you all this? That's because where the attached callback functions get queued depends on the type of API that registered them. There are two separate queues for both of them.

Macrotask Queue , also known as Callback Queue, tracks functions queued by Callback-based APIs.
Microtask Queue tracks functions queued by settled Promises.

Here, the queued functions wait for the Call Stack to be empty. Once empty, these functions are moved to the Call Stack in FIFO (First In First Out) order for execution.

The Event Loop handles this entire process. It is a mechanism that continuously monitors the call stack and the queues. Whenever the Call Stack is empty, it checks the Task Queues for queued functions and moves them to the Call Stack for execution, if there are any. This cycle repeats indefinitely as long as the application is running.

The Event Loop has a priority for the Microtask Queue. So, it first checks the microtask queue. If there are any microtasks, they are pushed to the call stack for execution until the queue is empty. Only after the Microtask queue is empty does it check the Macrotask queue. Okay, so if the Microtask queue has priority over the Macrotask queue, what will happen if there are a lot of Microtasks? Wouldn't the Macrotask Queue be starved?

You know what, I'll leave that for you to ponder. Think about it. Also, feel free to let me know what you got.

Non-blocking Concurrency Model

This entire flow we've been exploring, i.e., the Runtime Environment, Task Queues, Event Loop, and the orchestration of synchronous and asynchronous code, represents JavaScript's Non-blocking Concurrency Model.

Even though JavaScript is single-threaded, it achieves concurrency through this elegant system. The Engine never stops and waits for asynchronous operations to complete. Instead, it hands them off to the Runtime Environment and continues executing, allowing multiple tasks to be "in progress" simultaneously while keeping the main thread responsive and unblocked.

I know this has been a lot of theory stuff. So let me help you visualise this with a simple example. Take a look here.

console.log("Script start"); // sync
setTimeout(() => console.log("Timeout callback"), 0); // async (macrotask)
Promise.resolve().then(() => console.log("Promise microtask")); // async (microtask)
console.log("Script end"); // sync

Let's trace through this code and see how the JavaScript Runtime Environment handles it.

When the script starts running, the JavaScript Engine begins executing the synchronous code line by line. The first line, console.log("Script start"), is synchronous, so it executes immediately and prints "Script start" to the consoleno queues involved here - just straight execution.

Next comes the interesting part: setTimeout(() => { console.log("Timeout callback"); }, 0). Even though the delay is 0 milliseconds, this is still an asynchronous callback-based API call. The Engine doesn't execute the callback immediately. Instead, it hands this task over to the Runtime Environment and registers the callback function. The Runtime Environment will queue this callback in the Macrotask Queue once the timer expires, which happens instantly. But it still goes through the queue system because that's how asynchronous operations work in JavaScript.

The third line brings us another asynchronous operation: Promise.resolve().then(() => { console.log("Promise microtask"); }). It is a Promise-based API, and while the Promise resolves immediately, the .then() callback doesn't execute right away. The Runtime Environment queues this callback in the Microtask Queue, separate from the setTimeout callback we just saw.

Finally, we have console.log("Script end"), which is another synchronous operation. It executes immediately and prints "Script end" to the console. At this point, the Engine has executed all the synchronous code, and the Call Stack is empty.

Now here's where the Event Loop takes centre stage! With the Call Stack empty, the Event Loop checks the queues for any pending callbacks. Remember, it prioritises the Microtask Queue first? So it grabs the Promise callback from the Microtask Queue and pushes it to the Call Stack for execution, printing "Promise microtask". Only after the Microtask Queue is empty does the Event Loop check the Macrotask Queue and execute the setTimeout callback, printing "Timeout callback".

Here's our final output:

Script start
Script end
Promise microtask
Timeout callback

Pretty neat how the Event Loop orchestrates everything, right? It is JavaScript's Non-blocking Concurrency Model at work - the Engine stays responsive, processes synchronous code immediately, delegates asynchronous tasks to the Runtime Environment, and the Event Loop ensures everything gets executed in the proper order without ever blocking the main thread. And that's the beauty of JavaScript's approach to concurrency - it's simple, predictable, and incredibly effective at keeping applications responsive while handling complex asynchronous operations.

Wrapping Up

And there you have it! We've journeyed through the fascinating world of JavaScript's Runtime Environment and discovered how it enables JavaScript's Non-blocking Concurrency Model. From understanding how the Engine works with APIs and libraries, to seeing how Task Queues and the Event Loop orchestrate asynchronous operations, we've uncovered the magic behind JavaScript's ability to stay responsive while handling complex tasks.

I hope this deep dive helped clarify some of the mysteries of JavaScript execution! If you found this article helpful, I'd love to hear your thoughts. Did anything surprise you? Do you have questions about specific scenarios? Your feedback means a lot to me. So, feel free to connect with me on:

And if you enjoyed this article, don't forget to share it with fellow developers who might benefit from understanding JavaScript's inner workings.

Until next time, keep coding and stay curious! 🚀

Understanding JavaScript Execution with some Pizza

Anshuman Mahato — Sun, 02 Mar 2025 13:18:44 +0000

Welcome back, fellow developers! I'm excited to have you here for the next part of our JavaScript deep-dive series. The previous article explored the fundamental concepts and core features that make JavaScript a powerful language. Don't worry if you missed it - you can catch up here.

I was all set to explore JavaScript code execution. Now that I am here, all of a sudden, I am craving some homemade Pizza. You know what? How about we do both? After all, both coding and cooking are about following a recipe, executing steps in the right order, and creating something amazing from basic ingredients.

Today, we will unravel one of JavaScript's most intriguing aspectshow JS code is processed and executed. We'll peek behind the curtain to understand what happens when our JS code executes while baking a cheesy corn pizza.

So preheat your brain (and maybe your oven), and let's dive into this tasty technical adventure!

The JavaScript Engine

The execution of JavaScript code is handled by a program known as the JavaScript Engine or JS Engine. Just like Java requires JVM, JavaScript requires a JS Engine. All browsers and any other environment that executes JavaScript have a JS Engine, with Google's V8 Engine leading the pack as the powerhouse behind Chrome and Node.js. Firefox uses SpiderMonkey, Safari runs on JavaScriptCore, and several others.

The JS Engine has two key components - the Call Stack and the Heap. The Call Stack is where the code executes. On the other hand, the Heap is an unstructured memory space used for storing objects required by the code during execution. Think of JavaScript Execution as baking a pizza. The Cooking Area is your Engine, and the Cooking Counter is your Call Stack. The space over where you keep your ingredients is the Heap.

Before you begin with the pizza, you have to prepare the ingredients. You cannot put them directly into the oven. You chop the vegetables, prepare the dough, grate the cheese, etc. Similarly, before the engine can execute the code, it has to be processed and converted to a machine-understandable form. It must speak the computer's language - machine code.

Earlier, we saw how JavaScript uses a clever hybrid approach called JIT Compilation, combining the best of compilation and interpretation. While I prepare the toppings for my pizza, let's peek under the hood and see how JIT Compilation inside the JS Engine.

Just-in-Time Compilation

When code first arrives at the engine, something fascinating happens. The engine starts breaking down your code into meaningful pieces. It parses the code to segregate tokens holding some meaning to JavaScript, e.g., 'const', 'var', and 'for'. But it doesn't stop there. The engine then transforms these pieces into an Abstract Syntax Tree (AST) - a structured way for the engine to understand your code's intent. Let's take a simple example: for the line const a = 10;, here's what the AST looks like.

{
  "type": "Program",
  "start": 0,
  "end": 13,
  "body": [
    {
      "type": "VariableDeclaration",
      "start": 0,
      "end": 13,
      "declarations": [
        {
          "type": "VariableDeclarator",
          "start": 6,
          "end": 12,
          "id": {
            "type": "Identifier",
            "start": 6,
            "end": 7,
            "name": "a"
          },
          "init": {
            "type": "Literal",
            "start": 10,
            "end": 12,
            "value": 10,
            "raw": "10"
          }
        }
      ],
      "kind": "const"
    }
  ],
  "sourceType": "module"
}

Don't worry too much about the details of AST for now - but if you're curious to dive deeper, check out this article.

The parsing phase does more than create the AST it's your code's first quality check, handling transpilation, linting, and ensuring your syntax is spot-on. Once the engine parses the code to AST, it compiles this AST to machine code, which is then immediately put into the Call Stack for execution. Here's where it gets interesting. Initially, the engine generates a rough, unoptimised version of the machine code to get things up and running as fast as possible. Then, while your code is executing, it continuously works in the background to optimise this code for better performance.

While different JavaScript engines might handle these steps in their own ways, this is basically how Just-in-Time Compilation works in JavaScript. It's a clever balance between speed and optimisation.

Now that my toppings are ready, its time to bake the pizza. Lets do that alongside learning how the engine executes the compiled code.

Execution Context

Once the code is parsed and compiled, it is ready for execution. As stated previously, the Call Stack is responsible for executing the code. It does so using something known as an Execution Context.

An Execution Context is an environment where a piece of code executes. Each context is like a self-contained environment that includes not just the code in execution but everything it needs to run your variables, functions, objects, and more. Back to our cooking analogy, pots, pans, pizza trays, and all cooking vessels are the execution contexts.

We have two types of Execution Contexts: Function Execution Context and Global Execution Context. A Function Execution Context forms the environment for executing a function's code whenever we call it. Every function call creates a new separate execution context. The Global Execution Context is for the Top-Level code, i.e., the code which is not a part of any function. It is the first execution context to go into the call stack when execution begins. There is only one Global Execution Context, unlike Function Contexts, which can be many.

The code execution begins as the engine pushes the Global Execution context into the Call Stack. The code executes line by line until it hits a function call. Upon hitting a function call, the execution pauses for the current context, and its state is saved. The engine creates a new execution context for the called function and pushes it into the Call Stack on top of the current context. Control then moves to this new context, and execution starts from the first line of the function's body. This process is known as Context Switching. It happens every time the Call Stack encounters a function call.

Once the Execution Context successfully executes the last line of the function associated with the context, the Call Stack pops it off, and the control passes to the previous Execution Context. The execution resumes from the position where it stopped before context switching. The process continues until the Call Stack pops off the Global Execution Context.

Well, that was a lot of jibber jabber. Let's make some pizza and see this in action.

Code Execution in Action

Here's our pizza recipe. Let's see how our JS engine will process it.

function prepareDough() {
    console.log("Step 1: Preparing Dough");
    console.log(" - 2 cups all-purpose flour");
    console.log(" - 1 tsp yeast");
    console.log(" - 1/2 tsp salt");
    console.log(" - 1 tsp sugar");
    console.log(" - 3/4 cup warm water");
    console.log(" - 1 tbsp olive oil");
    console.log("Step 2: Mixing ingredients and kneading the dough.");
    console.log("Step 3: Letting the dough rest for 1 hour.");
}

function prepareSauce() {
    console.log("Step 4: Preparing Tomato Sauce");
    console.log(" - 1/2 cup tomato puree");
    console.log(" - 1/2 tsp salt");
    console.log(" - 1/2 tsp oregano");
    console.log(" - 1/4 tsp black pepper");
    console.log(" - 1/2 tsp garlic powder");
    console.log("Step 5: Cooking sauce for 10 minutes.");
}

function prepareToppings() {
    console.log("Step 6: Preparing Toppings");
    console.log(" - 1/2 cup grated mozzarella cheese");
    console.log(" - 1/2 cup sweet corn");
    console.log(" - 1/4 cup chopped bell peppers (optional)");
}

function assemblePizza() {
    prepareDough();
    prepareSauce();
    prepareToppings();
    console.log("Step 7: Rolling out the dough into a pizza base.");
    console.log("Step 8: Spreading the sauce over the dough.");
    console.log("Step 9: Adding cheese, corn, and other toppings.");
}

function bakePizza() {
    assemblePizza();
    console.log("Step 10: Baking Pizza");
    console.log(" - Preheating oven to 220C (430F).");
    console.log(" - Baking for 12-15 minutes until golden brown.");
}

bakePizza();

Once the engine compiles your code, it kicks things off by placing the Global Execution Context (GEC) in the Call Stack. First up, the engine scans through your code and sets aside memory for all your pizza-making functions: prepareDough(), prepareSauce(), prepareToppings(), assemblePizza(), and bakePizza(). When it hits the bakePizza() call, the engine pauses the Global Context, creates a fresh Execution Context for bakePizza(), and adds it to the Call Stack.

As bakePizza() springs into action, it needs assemblePizza() to do its job. The engine creates another Execution Context that jumps onto the Call Stack. Now, assemblePizza() starts with prepareDough() - yes, you guessed it, another Execution Context joins the stack! After logging the dough preparation steps and finishing its job, prepareDough() context checks out and leaves the stack, handing control back to assemblePizza(). The same sequence plays out for prepareSauce() and prepareToppings() - each gets its own Execution Context, does its thing with the toppings, and exits the stack when done.

With all preparations complete, assemblePizza() handles the final assembly - rolling dough, spreading sauce, and adding toppings. Once done, it exits the Call Stack, passing control back to bakePizza(). Now, bakePizza() can do its part - handling the baking instructions and logging the final messages. After it completes its tasks, it leaves the Call Stack as well.

When the Call Stack finally empties, we know our pizza-making program has completed its journey - all functions have done their jobs and returned home. And with this, my pizza is ready.

Speaking of which, writing this article has made me incredibly hungry. I think it's time for me to savour this tasty homemade pizza.

Wrapping Up!

So, we've reached the end of our delicious journey through JavaScript's execution process! We've learned how the engine processes our code, manages execution contexts, and handles the call stack. What seems like simple scripting is a highly optimised and synchronised process under the hood.

Thanks for reading! I hope this article was insightful for you. I'll leave you here to digest all this information. If you found this helpful, pass it along to your fellow developers (maybe include a pizza when you do)!

Want to connect? Follow me on:

Happy Learning!! 😊🙏

JavaScript Fundamentals You Should Know

Anshuman Mahato — Sun, 09 Feb 2025 11:06:52 +0000

Today, JavaScript is everywhere. Whether scrolling through your favourite social media feed, ordering takeout, or streaming music, JavaScript is quietly powering that smooth experience behind the scenes. If you are a Web Developer, you definitely use it one way or the other. JavaScript is the core of modern web development.

It's pretty mind-blowing when you think about it - this language has transformed from a simple website enhancement tool into the backbone of the entire web. But have you ever stopped to wonder about what is happening under the hood? What's going on when you click that button or submit that form? How does JavaScript communicate with your browser to make magic happen on your screen?

In this series, I will try to answer all these questions. If you have ever pondered these, follow along with me. Let's begin with the first article in this series.

What is JavaScript?

Across the internet, you'll find various answers: scripting language, high-level language, the language of the web and whatnot. Let me give you a descriptive definition of JavaScript.

"JavaScript is a High-level, Dynamically Typed, Multi-paradigm, Garbage Collected, JIT Compiled, Single Threaded programming language with First class functions and Non-Blocking Event Loop Concurrency model."

Well, I know that's a lot of technical jargon. But don't worry - we will break it into bite-sized pieces that anyone can understand.

Let's tackle the basics first - I promise it's not as scary as it sounds!

High-Level Language: These programming languages allow humans to write computer programs without specific knowledge of the hardware. That's how we work in JavaScript. We focus on program logic, not low-level hardware details like memory management.
Dynamically Typed: JavaScript is pretty laid back regarding how you declare variables. Unlike its stricter cousins (C, C++, and Java), which demand to know the exact type of data you're working with upfront, JavaScript figures it out by itself. We do not need to specify data types when declaring and defining variables.
Multi-Paradigm: JavaScript is versatile because it supports procedural, object-oriented, and functional programming paradigms. It doesn't force you into one way of coding. You can organize your code any way you want. JavaScript's got your back!
Garbage Collected: Garbage collection is a feature that tracks objects and variables created and frees their memory when they are no longer required. It is like having a tidy roommate who automatically cleans up after you. It keeps track of what you're using and what you're not, clearing out unused memory so your program runs smoothly.
First Class Functions: In JavaScript, functions are objects as well. They're not just actions. They're values you can play with. Do you want to hand a function to another function as a parameter? Go for it! Store it in a variable? Absolutely! Return it from another function? You bet!

Now that we've covered the basics, let's dive into more interesting stuff!

Just In Time Compilation

Have you ever wondered how your computer understands JavaScript? JavaScript is a high-level language. A computer cannot execute it directly; instead, we convert the code to a machine-understandable form. Across all programming languages, the conversion of source code to machine code happens in one of the following two ways -

Compilation: The entire source code is converted into machine code at once and is stored separately. Then, we use this compiled file for execution. It's like meal-prepping for the week - you do all the work upfront!
Interpretation: This is more like having a real-time translator at a conference. The code gets translated line by line as it runs, with the interpreter working on the fly. Every time you run the program, the translator needs to be there doing its thing.

Now, JavaScript? It's clever - it takes the "why not both?" approach. You may have heard that JS is an interpreted language. But that's not the complete truth. What JS does is known as JIT Compilation or "Just In Time" Compilation.

JIT Compilation in JavaScript combines the best of both compilation and interpretation. Like compilation, the entire code converts to machine code at once. But, we do not store it in a separate binary file. Instead, the machine code executes as soon as the compilation ends, like interpreted languages.

This approach allows JavaScript to start quickly like an interpreted language while achieving performance similar to compiled languages for frequently executed code. It's constantly adapting and optimizing based on how your code actually runs - pretty smart, right?

Different JavaScript engines (like V8 for Chrome or SpiderMonkey for Firefox) implement JIT compilation in their ways, but they all follow this general principle to balance speed and flexibility.

I won't get into the exact details. Let's leave that for another article (#contentPlanning 😁).

Single Threaded Programming Language

JavaScript is a single-threaded programming language. As a result, it can only do one thing at a time. Think of JavaScript as a one-track mind - it's like a chef with a single cutting board who can only chop one ingredient at a time. Here's what this means in practice:

Execution Order : JavaScript code is executed line by line, from top to bottom, one step at a time. No skipping ahead or multitasking!
Synchronous Execution : By default, JavaScript runs synchronously, meaning each line of code waits for the previous one to complete before executing.
Blocking Operations : If a particular operation takes a long time to complete, it will block the execution of subsequent code until it finishes.

Now, you might be scratching your head and thinking, "Wait a minute... if JavaScript can only do one thing at a time, wouldn't our apps freeze up whenever something takes too long?" Great question! Well, this is where the Event Loop comes into play.

Non Blocking Event Loop Concurrency Model

A non-blocking event loop is a programming model that allows a single-threaded application to handle multiple concurrent operations efficiently without getting stuck or blocking the main execution thread. In simple terms, this is what happens. When JavaScript encounters a time-consuming task (like fetching data from a server or reading a file), instead of standing around waiting, it hands it off to the background workers in the Runtime Environment and keeps moving forward with other tasks.

Once that background task is complete, the Event Loop acts like a notification system, tapping JavaScript on the shoulder to say, "Hey, that thing you asked for? It's ready!" It brings the callbacks or the continuation of that task to the main thread.

It is just scratching the surface of how the Event Loop keeps everything running smoothly. We'll dive deeper into all its inner workings when we explore the JavaScript Runtime environment!

Thats all for now !

Well, that's all in this brief overview of JavaScript. I hope it was helpful and informative for you. If your mind is buzzing with questions right now - perfect! That's what I was aiming for.

Stay tuned for the upcoming articles in this series, where we'll roll up our sleeves and dig deep into JavaScript's inner workings. No stone will be left unturned as we explore every nook and cranny of this fascinating language.

I'm super eager to hear your thoughts and experiences. If you want to connect with me, here are my socials:

Twitter
LinkedIn
GitHub

Thanks for joining me on this JavaScript adventure! Remember - the best developers are the ones who never stop asking, "but how does it work?" Keep that curiosity burning!

Managing Event Flow: A Deep Dive into JavaScript Event Propagation

Anshuman Mahato — Sun, 24 Mar 2024 17:10:54 +0000

Before we begin, let's consider a scenario. Say we're building a User card. It has the photo of the user, their name and a button to send a message to them. If we click anywhere on the card, a description of the user appears. If we click the send message button, a textbox appears to send them a message.

The design is simple. We develop the structure with HTML and CSS. As for the interactions, we add a click handler to the card, which opens the user details and a click handler to the button in the card that opens the message panel.

Yeah, that should work, right? Let's try it out and see for ourselves.

Well, it didn't work. You're right if you think that by clicking the button, we are indirectly clicking the card. Both the event handlers are executed when we click the send message button. So, how do we implement this?

To figure this out, we must first understand how JavaScript tracks the events in the DOM. We must determine when JavaScript executes the event handlers. We must learn about Event Propagation in JavaScript DOM.

Event Propagation - movement of Events through the DOM

JavaScript uses Event Propagation to handle how events travel through the Document Object Model (DOM) when an event occurs and reaches the target element, triggering further actions based on the event.

It happens in three phases - Capturing, Targeting and Bubbling.

1. Capturing - This is the first phase in the event propagation process. When an event is triggered, it starts from the root of the DOM tree and then moves down towards the target element. By default, event handlers are not executed in this phase.

2. Targeting - This phase starts once the event reaches the element where the event was triggered. Any event handlers associated with the target element for the particular event get executed in this phase.

3. Bubbling - After targeting, the event traces back its path and moves back up to the root of the DOM. It is in this phase that the event handlers execute. JavaScript executes the associated event handlers in order as the event moves up the DOM tree.

If you got this, you must have figured out what is happening in our example. When we click the button, the click event starts capturing. It first captures the .user element, then the .user__description and then the .user__cta, which is the button. Upon targeting the button, it renders the message panel as per the event handler. Then, it starts bubbling, and when it reaches the .user element, it executes the associated event handler and renders the details, replacing the message panel.

Now, we have figured out what is happening here. Let's see how we can deal with this.

Manipulating Event Propagation

As you must have understood, to make our example work, we must stop the propagation once the event handler for the button executes. We have two utilities for this - event.stopPropagation() and event.stopImmediatePropagation(). Both of them block the propagation of the event once encountered. There is only one difference in their work.

The event.stopPropagation() stops the event from going to the next element. All handlers associated with the current element for that particular event will still get executed. This does not happen in event.stopImmediatePropagation() where propagation stops immediately, and no event handlers execute even if they belong to the current element.

With this knowledge, let's update our solution.

Executing in the Capture Phase.

I said earlier that event handlers do not execute during the capture phase by default. You must be thinking if there is some way to do that. True, there is a way to do this. Ironically, the solution to this problem is also true.

You must have used the addEventListener() utility with two parameters to attach events to elements - the event type and the handler function. It also takes a third parameter called useCapture. Its default value is false. If we pass true to this, then the handler will be executed at capturing instead of bubbling.



element.addEventListener('click',handlerFn,true);

Well, here's a question for you folks. What will happen if we call event.stopPropagation() in a handler executed during the capture phase? Comment down the answers in the comment section 😉.

Optimization with Event Delegation

Event delegation is a technique where you delegate the event listener to the parent element to listen to events triggered by its children. We usually do this when the children perform similar actions upon an event.

Think of a Navbar with many links. Upon clicking a link, an associated dropdown menu opens. The direct way to do this will be to attach a listener to every link. But that would result in too many event handlers all doing almost the same task.

We can implement event delegation here to optimize this. We can attach the listener to the direct parent of the links. So, instead of having multiple listeners, we will have a single listener that will listen to clicks on any child link.

But how do we determine which link we clicked? For that, we look at the target property of the event. This property holds the node where the event was triggered. With it, we can determine the link we clicked and then open the respective dropdown accordingly.

That's how Event Delegation works. Here's the demonstration for the above example.

That's all I had to say

Hey there, we've come to the end of this article! I hope it was helpful and informative for you. I'm excited to hear your thoughts and feedback, so don't hesitate to drop a comment below.

By the way, if you want to connect with me outside of this platform, you can find me on Twitter, LinkedIn, and GitHub. Here are the links:

Twitter LinkedIn GitHub

Thanks for reading this far, and keep exploring new things!🌟

For intricate state handling, try out the useReducer() Hook

Anshuman Mahato — Sun, 17 Mar 2024 05:21:37 +0000

So, lately, I have been working on a form component. It was a registration form that had quite a few fields in it. The state management for this was not complex, but it was repetitive. Creating a state for each input field and updating it whenever the user interacts with them, I was writing the same code with minor differences.

let [fname,setFname] = useState("");
let [lname,setLname] = useState("");
let [email,setEmail] = useState("");
...

Also, I felt that all these pieces must be related to one another rather than being separate entities. So, I switched to using a single state with an object storing all input fields.

let [formData, setFormData] = useState({
   fname: "",
   lname: "",
   email: "",
   ... 
});

Even though the state was centralized, the event handlers still managed the state update logic.

const changeEmail = (e) => {
     const regex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/;

     if(e.target.value.match(regex))
         setFormData({...state, email: e.target.value});
};

I was looking for some way to centralize this as well. That's when I came across the useReducer() hook, a utility for complex state management.

Want to know about this? Just follow along with me.

What is this useReducer() hook, and how does it work?

The useReducer() hook is an alternative to the useState() hook that helps to manage complex states in a React application. In fact, the useState() hook uses the useReducer() hook behind the scenes itself.

The useReducer() hook takes a reducer function and the initial state as its parameter and returns an array. The first element of this array is the state object, and the second element is the dispatch function. At first, it might look very similar to useState(). But the working is very different here.

const [state,dispatch] = useReducer(reducer,initialState);

The state and the initialState is obvious. But, what is dispatch and reducer? Let's try to understand how all this works.

Reducer, Actions and Dispatch

The dispatch is analogous to the update function returned by the useState() hook. Both are used to update the state. The difference lies in how they work. Unlike the update function, where we pass the next state directly, we pass an Action here.

Now, you may ask, "What is this Action?". Well, An Action is an object that specifies how we want to update our state. You may structure your Action object as you wish. But conventionally, we have two fields in this object - type and payload. The type specifies the kind of update that we want to perform. The payload takes any external values that might be needed for the update.

dispatch({type:"ACTION TYPE", payload:"values to pass"});

What does the dispatch do with this Action object? It passes it to its associated reducer. The reducer is a function that maintains the logic for state updates for every action type. It takes the current state and an Action object as arguments and returns the updated state per the requested action. After this, the component is rendered according to the update state.

Let's try this out

Let us build a simple Counter App to see this working (cliche, I know). The application will have four functions -

We can increment the count by 1.
We can decrease the count by 1.
We can add some value to the count.
We can subtract some value from the count.

Let's begin with our initial state. It will only contain a field for the count.

const initState = {count: 0};

Now, we implement our reducer function.

function reducer(state,action) {
   const {type,payload} = action;
   const {count} = state;
   switch(type) {
      case "INCREMENT": return {...state, count: count + 1};
      case "DECREMENT": return {...state, count: count - 1};
      case "ADD": return {...state, count: count + payload.value};
      case "SUBTRACT": return {...state, count: count - payload.value};
      default: return state;
   }
}

It's time to implement our Counter component.

function Counter() {
  const [state, dispatch] = useReducer(reducer, initState);
  const [value, setValue] = useState(0);
  return (
    <div>
      <h1>{state.count}</h1>
      <button onClick={() => dispatch({ type: "INCREMENT" })}>Increment</button>
      <button onClick={() => dispatch({ type: "DECREMENT" })}>Decrement</button>
      <div>
        <input
          type="number"
          value={value}
          onChange={(e) => setValue(parseInt(e.target.value))}
        />
        <button onClick={() => dispatch({ type: "ADD", payload: { value } })}>
          Add
        </button>
        <button
          onClick={() => dispatch({ type: "SUBTRACT", payload: { value } })}
        >
          Subtract
        </button>
      </div>
    </div>
  );
}

export default Counter;

And with this, our component is complete. Copy this code and play around with it to understand things better.

Things to consider

Here are some points to remember when working with the useReducer() hook.

Do not use them anywhere and everywhere. Use it only where the structure of the state is somewhat complex. Otherwise, you'll be writing unnecessarily lengthy codes. For simple states, stick to the useState() hook.
Storing action types as constants is better than using literals. It helps in avoiding bugs due to typos.
Always return a new object from the reducer when updating the state. React makes a shallow comparison when comparing new and old states. Updating a particular field will not trigger re-renders.

That's all Folks

That's a wrap for now, folks! I hope this article was insightful to you. I look forward to your insights and feedback. Let's keep this conversation going in the comments below!

And hey, if you want to connect beyond these pages, these are the places where you can find me!

Twitter LinkedIn GitHub

Until next time, stay curious and keep exploring!🌟 Thank You for reading this far. 😊

Mastering React Context: Simplifying State Management and Prop Drilling

Anshuman Mahato — Sun, 10 Mar 2024 05:29:15 +0000

Many times, in react, state information is used by multiple components. Information in React is usually shared using props. We use it for this purpose as well.

To resolve such situations, we define that data/function at a common parent component and then move it down using props. We call it lifting the state.

The Context API is an alternative to this. A context defines a scope with some information. All the components placed in this scope can use that information directly. In my opinion, it is similar to namespaces in C++.

The Problem with Props

Although passing props is a perfectly valid solution, it often creates an issue. There might be situations where the common parent is far from the actual component. So, we will need to move the data very deep down the UI tree and make it unnecessarily verbose. This issue is called "Prop Drilling".

Let's take an example to understand this. Let's say we have a CRUD app related to Books. Following is the structure of this application.

<BookCreate /> - Creates entry for the book.
<BookList /> - Shows all the Books
<BookShow /> - Display component for each book.
<BookEdit /> - Component to editing book information.

The books array is a state variable that contains all the books, and createBook, editBook, and deleteBook are functions that manipulate the state.

As we can see, all the components use the books state. So, we declare in the App component. So are the functions that manipulate it.

Now, these functions need to be moved way down the component tree. We will require a lot of props, resulting in prop drilling.

We can avoid this issue using Contexts. Context lets a parent component provide data to the entire tree below it.

Implementing Context

To implement a Context, you need to do the following three steps:

Creating a context
Provide the context scope
Use the Context

Creating a Context object

We use the createContext() method for this.

import {createContext} from "react";
const Context = createContext(defaultvalue);

This method returns a context object.

Providing the Context

Now, we create a scope using this context object. Here, we define the values to pass to the child components. The context object has a provider component for this purpose.

<Context.Provider value={valueToShare}>
      {children}
</Context.Provider>

This component has a value prop through which we associate values with the scope. The value of this prop becomes available to all the children components of the Provider component.

Using the `context` object

The children components extract these values using the useContext() hook.

import {useContext} from "react";
const value = useContext(Context);

This hook takes the context object as an argument and returns the values that are associated with it.

Here's an example with a simple implementation using contexts.

//Context.jsx

import { createContext } from "react";

const Context = createContext(1);

export default Context;

//Container.jsx

import React, { useContext } from "react";
import Context from "./Context";

function Container() {
  const value = useContext(Context);
  return <div>{value}</div>;
}

export default Container;

//App.jsx

import React from "react";
import Context from "./Context";
import Container from "./Container";
function App() {
  return (
    <Context.Provider value={5}>
      <Container />
    </Context.Provider>
  );
}

export default App;

This way, information is shared between components without using any prop for passing data.

Some Extra bits on contexts

We can create multiple scopes using the same context object. We can provide each of them with different context values that the components within them can access. Replace the App code with the following code in the above example to see it live.

   function App() {
     return (
       <div>
         <Context.Provider value={3}>
           <Container />
         </Context.Provider>
         <Context.Provider value={7}>
           <Container />
         </Context.Provider>
       </div>
     );
   }

We can also define a scope within another scope of the same context object, and both will provide different values to their child components. Here, a child can access all the data values belonging to the nearest parent Provider. Replace the App code with the following code in the above example to see it live.

function App() {
  return (
    <div>
      <Context.Provider value={3}>
        <Container />
        <Context.Provider value={7}>
          <Container />
        </Context.Provider>
      </Context.Provider>
    </div>
  );
}

If a non-child component tries to use it, it gets the default value passed during the createContext(defaultValue) call. In such a situation, React searches for a parent provider for it. But as it does not find one, it returns the default value as a fallback. Replace the App code with the following code in the above example to see it live.

function App() {
  return (
    <div>
      <Context.Provider value={3}>
        <Container />
      </Context.Provider>
      <Container />
    </div>
  );
}

Practical Use Case

The most common use of contexts is State Management. Prop drilling often happens due to the sharing of state information between components. What would be better is to create a context for the state and put the component tree associated with that state within that.

Let's see our book example again. We declared the books state and associated methods in the App component. We then moved them to the actual location via props.

Alternatively, we can define the books state and the methods in a context and provide it to the App component. This way, the App and all its children components have access to the books state directly.

Here's the code for it

Some Consideration

Contexts are great tools for passing data deeply in a UI tree without tending to prop drilling. They are simple to implement, making it very tempting to use them. Thus, we may end up overusing them. To avoid this, we must understand the association between the information and the components using it.

If the information is associated with components which are related and mutually dependent on one another, it might be better to use the prop system as it would make the data flow explicit between them. For example, let's say we have a Form component with multiple form controls. Different form controls may depend upon the states of one another and thus require the sharing of information. Here, using props would be better as it would depict how data flows within the Form component.
On the flip side, if the information is associated with mutually independent components, it is better to use contexts. An example of this could be login information. We can use this in the navbar to show the username. We can use this on the profile page to display user details. We can use it application-wide, irrespective of the relationship between the components.

That's all folks

Contexts are great for sharing information when it needs to be moved deeply in a component tree. It is simple to implement and helps in clubbing data in one place.

This article is my understanding of the context API. You may give your insights in the comments. I would appreciate your feedback.

And hey, if you want to connect beyond these pages, catch me on Twitter! My handle is @AnshumanMahato_.

With this, I would like to conclude this post. Until next time, stay curious and keep exploring! 🌟Thank You for reading this far. 😊

Exploring React Hooks: Simplifying State and Lifecycle in Functional Components

Anshuman Mahato — Sun, 03 Mar 2024 04:39:24 +0000

In the React library, we have two types of components - the class components and the functional components. The difference is that class components are stateful, whereas the other ones are stateless. Well, that's what it was before React 16.8.

Every component in React goes through three phases - Mounting, Updating and Unmounting. It is known as the React Component Lifecycle. There are various methods to access these stages (see here). Only The class components had access to the state and lifecycle methods. It was not available to the functional ones. They were just simple javascript functions that took input parameters or props and returned an HTML component for rendering.

All of this changed with the introduction of Hooks in React 16.8.

What are Hooks?

The Hooks API allows the Functional components to 'hook' into their state and lifecycle phases. So now, they can do everything that was previously possible only in Class-based components.

There are only some rules that we need to follow when using hooks.

We can only call Hooks inside React function components.
We can only invoke them at the top level.
Hooks cannot be conditional.

Using Hooks requires us to write less code when compared with class-based components. They decouple the logic from the UI. At the same time, they also keep related logical units in one place. All of this allows for easy sharing of stateful logic between components. It makes the code more reusable. The community widely accepted the Hooks API for these reasons.

Let's see how we can do all this with hooks.

Managing State with Hooks

State management is a necessary part of any application. In class components, we have the state field, which is an object containing all the state variables.

For functional components, we have the useState hook. This hook takes the initial value for the state variable and returns an array. The first element of this array is the state variable, and the second one is its setter function, which we will use to change its value as needed. The component re-renders every time the state is updated.

import React, { useState } from 'react';

function Counter() {
  let [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

Looks cool, right?

The initial value can be anything from primitive data types like string, number, and boolean to compound data types like Objects and Arrays.

To update the value, we use the setter/update function. We can either pass the new value or a function which takes the current state value as the parameter and returns the new value for the state. We use functional updates in places where the new value depends on the previous one.

//putting new value
setCount(10);

//functional update
setCount((current) => (current + 1));

A thing to note is that when using compound types as state, one must not mutate the existing value for update. Instead, they must give a new object or array.

let [state, setState] = useState({
   name: "Akhilesh Pal",
   job: "SDE"
});

//method 1
setState({...state, job:"Programmer"});

//method 2
setState(current => ({...current,job:"Programmer"}));

If not done like this, react will not trigger re-render. It happens due to the way JS handles data.

Performing side effects during the Lifecycle Phases

A react component goes through the following three phases in its lifecycle - mounting, updating and unmounting. The Mounting Phase begins when a component is created and inserted into the DOM. The Updating Phase occurs when a component's state or props change. And the Unmounting Phase occurs when React removes it from the DOM. Often, we perform some actions when these events happen, like API calling or some calculations.

For Class Components, we have various methods like componentDidMount(), componentDidUpdate(), componentWillUnmount() and many more to access these events. In Functional Components, we have the useEffect hook. It is a hybrid that can do the combined task of the three methods mentioned previously.

import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

The useEffect() hook takes an effect function and a dependency array as an argument. This effect function executes when the component mounts and on further updates based on the dependency array. The dependency array takes a set of state variables that it tracks for updates. If any of their value changes, then it executes.

/* If we don't provide a dependency array, the effect will run on every re-render */
useEffect(() => {
  console.log("Effect running on every re-render");
});

/* If we provide an empty dependency array, the effect will run only on the mount phase */
useEffect(() => {
  console.log("Effect running only on mount phase");
}, []);

/* If we provide a dependency array with some variables, the effect will run on re-render if their value is updated */
const [count, setCount] = useState(0);

useEffect(() => {
  console.log("Effect running on re-render if count is updated");
}, [count]);

So, useEffect takes care of the Mount and the Update phase, but what about Unmount? Well, it handles that as well. What we do is return a cleanup function from the effect function. This function executes before every re-render and upon Unmount.

import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const timer = setInterval(() => {
      setCount(prevCount => prevCount + 1);
    }, 1000);

    // Cleanup function to clear the timer when the component unmounts
    return () => {
      clearInterval(timer);
    };
  }, []);

  return (
    <div>
      <p>Count: {count}</p>
    </div>
  );
}

export default Example;

Referencing

Sometimes, we want data to persist upon re-render but not cause a re-render when its value is updated. For example, let's say there is an interval in our project that we stop at some event. We need to store its 'id'. This 'id' is not going to be rendered. Hence, this is a perfect use case for references.

For creating references, we have the useRef hook. It returns a reference object. This object has a current property that holds the current value for the reference. We can pass the initial value for the reference as an argument to the hook.

import React, { useRef, useState } from 'react';

function Counter() {
  const intervalRef = useRef(null);
  const [count, setCount] = useState(0);

  const startTimer = () => {
    // Start a timer that increments count every second
    intervalRef.current = setInterval(() => {
      setCount(prevCount => prevCount + 1);
    }, 1000);
  };

  const stopTimer = () => {
    // Stop the timer when the button is clicked
    clearInterval(intervalRef.current);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={startTimer}>Start Timer</button>
      <button onClick={stopTimer}>Stop Timer</button>
    </div>
  );
}

export default Counter;

We also use Refs to reference DOM elements. Sometimes, we might need access to the DOM elements managed by React—for example, to focus on a node, scroll to it, or measure its size and position. One way to do this could be to use a JS query selector. But, the correct way to do this in React is to use refs.

import React, { useRef } from 'react';

function TextInputWithFocusButton() {
  const inputRef = useRef(null);

  const focusInput = () => {
    inputRef.current.focus();
  };

  return (
    <div>
      <input ref={inputRef} type="text" />
      <button onClick={focusInput}>Focus Input</button>
    </div>
  );
}

Improving Performance with Caching

A React component re-renders multiple times across its lifecycle. All its variables and functions are redeclared and refined on every re-render. It might not be an issue for simple variables as the older ones will get garbage collected. But let's say there is some variable whose value gets assigned after an expensive computation. This computation happens each time the component re-renders, affecting performance. It will be better if we cache this value and re-evaluate only when the parameters for calculation update.

We use the useMemo hook for this exact purpose. It takes the compute function and the dependency array. It memoizes the result and recalculates only when something from the dependency array updates. Its syntax is similar to that of useEffect.

import React, { useState, useMemo } from 'react';

function ExpensiveComponent({ number }) {
  const expensiveComputation = useMemo(() => {
    // Simulating an expensive computation
    let result = 0;
    for (let i = 0; i < number; i++) {
      result += i;
    }
    return result;
  }, [number]);

  return <div>{expensiveComputation}</div>;
}

The useCallback hook does the same thing, but for functions. One of its uses is memoizing event handlers. Otherwise, they will get refined on every re-render.

import React, { useState, useCallback } from 'react';

function Button({ onClick, children }) {
  return <button onClick={onClick}>{children}</button>;
}

function App() {
  const [count, setCount] = useState(0);

  const increment = useCallback(() => {
    setCount(count + 1);
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <Button onClick={increment}>Increment</Button>
    </div>
  );
}

Custom Hooks

There are situations when we use similar hooks or a set of hooks in different components. As you can see, this will cause a lot of repetition. It goes against code reusability.
We can solve this by clubbing all these hooks into a custom hook. All we have to do is create a function whose name starts with use. For example, useCustomHook. Within this, we call all the hooks. Then, we use this hook instead.

import React, { useState, useEffect } from 'react';

function useDocumentTitle(title) {
  useEffect(() => {
    document.title = title;
    return () => {
      document.title = 'React App'; // Reset title on unmount
    };
  }, [title]);
}

function Counter() {
  const [count, setCount] = useState(0);
  useDocumentTitle(`You clicked ${count} times`);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

That's all Folks

That's a wrap for now, folks! I hope you enjoyed diving into this blog as much as I enjoyed sharing it with you! But it doesn't end here – your insights and feedback mean the world to me! Let's keep this conversation going in the comments below!

And hey, if you want to connect beyond these pages, catch me on Twitter! My handle is @AnshumanMahato_.

Until next time, stay curious and keep exploring! 🌟Thank You for reading this far. 😊

Learning Journal - Digileger Project Log

Anshuman Mahato — Sun, 23 Jul 2023 07:40:29 +0000

I recently started using Twitter and came across this trend of #learninpublic. I saw many people logging their daily progress. It was inspirational to see fellow developers supporting each other in upskilling. It gave me the idea of logging my learnings through blogs. So, here I am.

A couple of months back, I started learning React and Tailwind. At the time, I was also thinking about building an application to track my expenses and budgeting. So naturally, it came to me that it would be a great project to practice my learnings. And so I began.

I planned to build a CRUD application where I could enter the details of my transactions, and it could process those to provide monthly analytics and cumulative data.

Here's what I made, Digiledger, a transaction management and expense-tracking app.

Here are the base features that I have integrated till now.

Record Transactions
Transaction Filtering
Expense and Income Analytics

Here are the links:
Live Site: https://digiledger.vercel.app/
Frontend Repo: https://github.com/AnshumanMahato/Digiledger-Frontend
Backend Repo: https://github.com/AnshumanMahato/DigiLedger-Backend

I have plans to expand this project with some more features. But that's all about it for now. This article is more about the things I learnt while building this project.

Build projects to learn stuff, and share your learnings to solidify them.

Working on stuff is the best way to learn anything. There is no questioning this. Along with learning, it also builds the confidence to work with stuff. That's what this project helped me with. I figured out React faster and got some interesting insights.

Here are the major stuff that I learnt:

Frontend First or Backend First?

In my previous projects, I mostly worked on the backend. I never faced any issues as I had the guidelines around which I had to work. I got the list of endpoints, their request body and their responses. So it was never a problem.

It was the first time that I started building everything from scratch. And being a backend guy, I jumped their head first. And it was very cumbersome. I had the endpoints figured out. What was difficult was figuring out the request and response structures.

As working on the backend became tiring, so I switched to the frontend. And that's when things became a lot clear. Knowing how we present data gives us a clear understanding of what we receive and send.

I spoke with some of the developers regarding their workflows. Some began with the design and frontend part with a mock API. After a basic structure is ready, they move to the backend. And then keep switching back and forth, as needed. Others said they did the backend first and then integrated the frontend.

At first, I thought it must be an "each to their own" thing. But upon thinking it through, I finally got it. It's not frontend first or backend first. It's planning that needs to done first.

Planning out designs, mockups, architecture, etc. and documenting them at the beginning is crucial for the development process. They provide a boundary for the application. It simplifies the scope of the application.

And I also realized that my design skills are not so good. I need to do some work on it.😅

Working of useEffect

From articles and tutorials, my initial understanding of useEffect was that the function within it executes at first render, and then it is called based on the dependency array. I thought that it all happened sequentially.

Let's see the following example.

import "./styles.css";
import { useEffect, useRef } from "react";

export default function App() {
  const testArr = useRef();

  useEffect(() => {
    testArr.current = ["kratos", "atreus", "mimir", "sindri", "brok"];
  }, []);

  return (
    <div className="App">
      {testArr.current.map((el) => (
        <p>{el.toUpperCase()}</p>
      ))}
    </div>
  );
}

If I go by my initial understanding, this is how it executes. First, testArr is declared, then useEffect executes, and then the component is rendered.

And boy, I was so wrong. The console sent me greetings "Cannot read properties of undefined (reading 'map')".

I did a lot of pondering and tried different solutions, but nothing worked. But then it struck me. All articles and tutorials always referred to the function as useEffect callback. I finally understood what was happening. First, we declare the testArr initially undefined. Then useEffect executes, and the callback's context to the callback queue. Then the component is rendered. After this, when the execution stack becomes empty, the callback is picked from the callback queue and is executed. And then, the component is re-rendered based on value changes.

So testArr = useRef([]) solves the issue. At first, it was a eureka moment, but then I felt dumb for not going through the resources thoroughly.
What I learnt from all this was a good understanding of useEffect and why it is essential to have appropriate initializations for states and refs.

Working with httpOnly cookies in Cross-Site situation

I am using JWT tokens for authentication. Storing it in local storage makes it vulnerable to XSS (Cross-Site Scripting) attacks, so I am using httpOnly cookies. The concept is that once we receive an httpOnly cookie from a host, the browser sends it with every request to that host as long as the browser has it. As httpOnly cookies are not accessible by client-side scripts, it prevents XSS attacks.

I have used this strategy in most of my previous projects. It always worked fine. But this time, it didn't work. The browser was receiving the cookie but was not sending it back. There was no error either in the browser console or on the server. I googled "browser not sending cookie to server" but got nothing.

Although I didn't find any resolution, there were mentions of CORS policies, origin header, sameSite and CSRF attacks on cookie-based authentication. My frontend and backend are independent applications. They were working on separate ports, so it was a cross-site situation. So, even if I didn't understand it much, I had a hunch that this might be the problem (and I was right).

As we know, we send the httpOnly cookie to its host with every request. It happens by default only if the client and server are on the same domain. It would have worked if I had served my frontend as static files. Or if I had used server-side rendering like my previous projects. But we have to specify this explicitly for cross-site requests. In Axios, we set the withCredentials config field.

    axios.get(BASE_URL + '/todos', { withCredentials: true });
// default for all requests
    axios.defaults.withCredentials = true
// only with a group of requests
    const instance = axios.create({
        withCredentials: true,
        baseURL: BASE_URL
    })
    instance.get('/todos')

In Fetch API, we use the credentials config field. It takes one of the
three values,

If you only want to send credentials if the request URL is on the same origin as the calling script, add credentials: 'same-origin'.
To cause browsers to send a request with credentials included on both same-origin and cross-origin calls, add credentials: 'include'.
To instead ensure browsers don't include credentials in the request, use credentials: 'omit'.

fetch("https://example.com", {
  credentials: "include",
});

We set the Access-Control-Allow-Credentials response header to true on our server.

But even after this, it didn't work. After some research, I found that it was due to protection against CSRF attacks.

CSRF stands for Cross-Site Resource Forgery. Let us understand this by an example. Assume a system where the frontend is at www.front.com and the backend is at www.back.com. What we intend is to do API calls from www.front.com to www.back.com. But let's say the user goes to a hoax website, www.trustmebiro.com. It silently does some API calls to www.back.com. As cross-site is allowed, this would work fine, as we only need the token cookie for authentication. Thus, we provide unauthorized access to unintended clients and become vulnerable to data breaches.

The SameSite attribute can be set in the cookie options to prevent CSRF attacks. It can take any of the values,

Strict - your cookie will only be sent in a first-party context. In user terms, the browser sends the cookie only if the site for the cookie matches the site currently shown in the browser's URL bar. However, when following a link to your site, say from another site or via an email from a friend, the browser will not send the cookie on that initial request. It is good when you have cookies relating to functionality that will always be behind an initial navigation, such as changing a password or making a purchase, but it is too restrictive.
Lax - If your reader follows the link into the site, they want the cookie sent so their preference can be applied. That's where SameSite=Lax comes in by allowing the browser to send cookies with these top-level navigations.
None - With this option, the browser will send the cookie with all requests, irrespective of the origin. But with this, the cookie must have the Secure attribute. It ensures that we send the cookie only over an HTTPS connection. Also, we need to include the The Access-Control-Allow-Origin in our CORS policies.

The last option is what I had to do. So, after all this, I finally made my app work as I intended. It was tedious. But I learned many things about Internet attacks, CORS policies, server configurations and networks.

Cancellation of Requests upon component unmount

After all this, the minimal features of the app were complete. So I deployed it. I used free services to deploy my app, so the performance was slow. It got me thinking about users with slow connections.

There was no loading screen in my app. So there was no indication that something was happening. Therefore I made one. It also got me thinking, what if the user tries to navigate when a request is ongoing? By the time response comes, they will be on a different page. It will have no use. So I started looking for ways to cancel a pending request upon component unmount. And I got to learn about the AbortController.

As per MDN, the AbortController interface represents a controller object that allows you to abort one or more Web requests as and when desired. It has a property signal and an instance method abort().

Here's how we use it with Axios.

const controller = new AbortController(); 
axios
    .get('/foo/bar', { signal: controller.signal })
    .then(function(response) { 
         //... 
    }); 

// cancel the request 
controller.abort();

Although this looks simple, I am facing difficulty integrating it with React. Till now, I have figured out how to implement it for requests we make within useEffect callbacks. Here's how we do it.

import axios from "axios";
import {useEffect} from "react";

function Component() {
useEffect(()=>{
    const controller  = new AbortController();
    (async()=>{
        const response = await axios.get('www.example.com',{
            signal: controller.signal,
        })
        //further manipulations
    })();

    return ()=>controller.abort();
});

return (<div>
        {/*Component body*/}
    </div>)
}

I still need to figure out how to do it for requests triggered based on user actions, like logins or transaction creation. I am looking into it. If you have any suggestions, please let me know in the comments.

Well, That's all, folks!

That's everything that I have gathered till now through this project. As I said earlier, it has been a great learning experience. I need to figure out much more stuff. A lot of work that I need to do on this project. But whatever I have done so far, it was fun.

I hope this blog was insightful for you. If you have any suggestions or feedback regarding anything, please comment. Or you may connect with me on Twitter as well. My handle is @AnshumanMahato_.

Thank You for reading this far. 😊

Scalability, Complexity and Complexity Analysis

Anshuman Mahato — Thu, 15 Jul 2021 04:43:26 +0000

As we know, the two characteristics of a good code are that it should be readable and scalable. As far as Readability is concerned, it means writing code that is understandable, not just to you but to others in your team as well. As for Scalability, what we try to ensure is that code must perform efficiently under most circumstances. That's it.

Now you would say, "That's vague. What exactly is Scalability? How do I make my code more Scalable?" Let's break this down step by step.

What is a Scalable Code?

When talking about scalable code, the question we try to answer is, "How will my code perform when the load increases?" It is all about code performance. When it comes to performance, a code must do two things:-

It should manage memory well.
It should perform in optimum time.

Memory is a limited resource. If the code does not manage memory then, it may run out of memory. The same holds for processing time. If it takes a lot of time to process a request, the waiting will become tedious for the user.

The memory requirements and required runtime of a code are respectively known as Space Complexity and Time Complexity. These are collectively known as computational complexities, and we determine these through Complexity Analysis.

So we have once again hit a bunch of jargon. Let's move along and demystify these as well.

Time Complexity and Space Complexity

In simple terms, Time Complexity represents the amount of time required by your code and Space Complexity represents the amount of memory occupied by your code to complete processing. Both Space and Time Complexity do not give the actual memory requirement or processing time of an algorithm. Instead, it provides an idea of the trend in which the memory requirements and processing time will change as the length of the input changes. Thus, they represent a function dependent on the input length.

Time Complexity predicts the number of operations required instead of the actual runtime. It is because the actual runtime of an algorithm is dependent on the hardware. It will differ from one system to another. Hence, it's not a constant value. On the contrary, the number of operations required will remain constant for a given input. As we can say, the time taken for execution will be proportional to the steps to be performed. This way, we can indirectly predict how much time it will take to process the given input.

Also, while calculating the Space Complexity of any algorithm, we usually consider only the amount of space used by the variables and constants. So, from Space Complexity, what we try to understand is "For a given input length, how many new variables does the algorithm create, that is, how much more memory does it acquire."

Complexity Analysis and Asymptotic Notations

As we can understand, Complexity Analysis is a way of determining the algorithmic complexities of the code. The complexity of an algorithm is calculated based on the input. Now, there will be input cases where the code will run fast. And for some cases, the code might get very slow. To account for this, we calculate complexity for three different cases, the Best case, the Average case and the Worst case.

The Best case is the set of inputs for which the algorithm takes a minimum number of steps on input data of n elements. The Worst case is the set for which the algorithm performs maximum operations on input data of size n. The Average case depicts the average random input set.

Now the question is, how do we represent these complexity values? Well, for this purpose, we use Asymptomatic Notation. Let's continue further to build an understanding of this as well.

Asymptotic notations are the mathematical notations used to describe the computational complexities of an algorithm when the input tends towards a particular value or a limiting value. There are three different notations used to describe the three cases.

The Omega Notation (Ω-notation) describes the Best case scenario.
The Theta Notation (Θ-notation) denotes the Average cases.
The Big-O Notation (O-notation) describes the Worst cases.

Most of you must have read or heard about the Big-O notations. It is the most commonly used one. As we know, the entire purpose of Complexity Analysis is to manage the worse cases and make the code more scalable. Hence, we programmers are particularly interested in Big-O.

Conclusion

In this article, we discussed Scalability and Algorithmic Complexity. We also discussed Time Complexity and Space Complexity and how we represent them using asymptotic notations. We also briefly discussed the Best case, Worse case and Average case scenarios.

I hope this article was helpful to you. If you think that something is missing, feel free to add those in the comments. I'm new to all this and would love to enhance my knowledge. And with this, I would like to conclude. Happy Coding!!!

Readability

Anshuman Mahato — Wed, 20 Jan 2021 11:08:47 +0000

For a code to be readable means that, it should be understandable to humans as well, along with computers. Sure, it will be a computer which will execute your code, but in the end, it will always be a human who'll manage it. So make sure that you write code which is understandable to other people in your team. Even if you prefer working solo, do care about readability. Believe me! Your future self would thank you for doing so.

So, how do we make our code more readable? Well, here we go.

Always use comments
Follow a consistent coding style
Give meaningful variable names
Do not repeat yourself
Refactor your code often

Always use comments your code.

It is useful to use them to explain complex code. They will help you and others understand why you did what you did. But, there is a fine line between helpful comments and redundant ones. So, have an understanding of what needs comments and what doesn't.

Follow a consistent coding style.

Have a consistent coding style all across your codebase. Inconsistencies often create confusion. Leave the same amount of space every time, create every block in the same pattern. If you start working on code that was written by someone else, follow the same style.

Give meaningful variable names.

Always name your variables in context to what they represent. It makes the working of the code easier to understand. A friendly tip, when naming booleans, name them as a verb.

Keep it DRY.

What it means is, "Don't Repeat Yourself". If you have snippets that repeat itself in your code, create a function for those snippets. It facilitates both readability and debugging.

Refactor your code as often as possible

Refactoring is improving the internal structure of an existing source code while preserving its functionality. Codebases grow. As a simple class gets more responsibility, it grows in size and complexity. They can stay readable only through continuous refactoring. The new, complex class might be broken into multiple parts or changed other ways to stay easy to read.

What is your idea about code readability? Do share your thoughts in the comments.

What is a Good Code?

Anshuman Mahato — Thu, 14 Jan 2021 15:14:07 +0000

When I started with programming, to me, it was all about getting the job done. I was clueless about things like readability, scalability, commenting and all. Adding to this, I strongly believed in this idea - "If it works, don't touch it."

This ignorance was so evident in my code that anyone who would have read that could have told that either I don't know about it or I don't care, both are signs of a naive programmer. Because of this, I always found myself in situations where even I couldn't understand my code.

Well, it was all until one day when I came across this meme.

I got curious about this code review thing and did some google. That's when I came to know about things like code quality, efficiency, data structures and other necessary elements of a Good Code.

So, what exactly does it take for a snippet to be a Good Code? From what I understood, in a broad context, it should meet the following criteria.

It should be readable.
It should be scalable.

What does it mean for a code to be readable?

By saying that the "code should be readable", what I mean is that is should be understandable. Not just to the computer or you. But also to people who are working on your code and who will manage your code in future. It should have a consistent coding style.

What does it mean for a code to be scalable?

By saying that the code should be scalable, what I mean is that the code should perform at par with the load. It should be able to manage user requests efficiently and accurately. It should be able to compensate in case the load increases and should utilize the hardware. In a broad context, it should be adaptable to change. Higher the adaptability, the more is the scalability.

What do you guys think makes a Good Code? Share your views in the comments. And if you liked this post or found this post meaningful, do hit ❤ .

See you next time. Until then, keep learning, keep hustling.

Forem: Anshuman Mahato

Inside JavaScript Runtime Environment

The JavaScript Runtime Environment

APIs and Libraries

Task Queues and the Event Loop

Non-blocking Concurrency Model

Wrapping Up

Understanding JavaScript Execution with some Pizza

The JavaScript Engine

Just-in-Time Compilation

Execution Context

Code Execution in Action

Wrapping Up!

JavaScript Fundamentals You Should Know

What is JavaScript?

Just In Time Compilation

Single Threaded Programming Language

Non Blocking Event Loop Concurrency Model

Thats all for now !

Managing Event Flow: A Deep Dive into JavaScript Event Propagation

Event Propagation - movement of Events through the DOM

Manipulating Event Propagation

Executing in the Capture Phase.

Optimization with Event Delegation

That's all I had to say

For intricate state handling, try out the useReducer() Hook

What is this useReducer() hook, and how does it work?

Reducer, Actions and Dispatch

Let's try this out

Things to consider

That's all Folks

Mastering React Context: Simplifying State Management and Prop Drilling

The Problem with Props

Implementing Context

Creating a Context object

Providing the Context

Using the context object

Some Extra bits on contexts

Practical Use Case

Some Consideration

That's all folks

Exploring React Hooks: Simplifying State and Lifecycle in Functional Components

What are Hooks?

Managing State with Hooks

Performing side effects during the Lifecycle Phases

Referencing

Improving Performance with Caching

Custom Hooks

That's all Folks

Learning Journal - Digileger Project Log

Build projects to learn stuff, and share your learnings to solidify them.

Frontend First or Backend First?

Working of useEffect

Working with httpOnly cookies in Cross-Site situation

Cancellation of Requests upon component unmount

Well, That's all, folks!

Scalability, Complexity and Complexity Analysis

What is a Scalable Code?

Time Complexity and Space Complexity

Complexity Analysis and Asymptotic Notations

Conclusion

Readability

Always use comments your code.

Follow a consistent coding style.

Give meaningful variable names.

Keep it DRY.

Refactor your code as often as possible

What is a Good Code?

What does it mean for a code to be readable?

What does it mean for a code to be scalable?

Using the `context` object