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:

• X: @AnshumanMahato_

• LinkedIn: /in/anshuman-mahato/

• GitHub: /AnshumanMahato

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! 🚀

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:

• X: @AnshumanMahato_

• LinkedIn: /in/anshuman-mahato/

• GitHub: /AnshumanMahato

Happy Learning!! 😊🙏

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:

1. Execution Order: JavaScript code is executed line by line, from top to bottom, one step at a time. No skipping ahead or multitasking!

2. Synchronous Execution: By default, JavaScript runs synchronously, meaning each line of code waits for the previous one to complete before executing.

3. 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!

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:

1. Creating a context

2. Provide the context scope

3. 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

This article is my understanding of the context API. 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.

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. 😊

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 are obvious. But, what are 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 -

1. We can increment the count by 1.

2. We can decrease the count by 1.

3. We can add some value to the count.

4. 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.

1. 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.

2. Storing action types as constants is better than using literals. It helps in avoiding bugs due to typos.

3. 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.

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. 😊