DEV Community: Azhar Dev

0 to 1 — Asynchronous JavaScript

Azhar Dev — Sun, 14 Aug 2022 09:09:16 +0000

If you have put some effort into learning actually is JavaScript. You must be really confused, as I was when I was understanding this beautiful language. Let me tell you why I was confused at that time, and probably your reasons should be similar too. If you research JavaScript, you usually get two types of statements.

JavaScript is a single-threaded, synchronous, blocking programming or scripting language.

Let's break this statement down;
Single-threaded: JavaScript is single-threaded in nature because the browser executes the complete script in a single execution thread. JavaScript engine executes our program sequentially one after another, a statement by statement.

Synchronous: JavaScript is synchronous in nature because everything is executed in sync. The next statement(program)has to sit and wait until the currently executing one is completed. Once the program is completed, the next one becomes active.

Blocking: As JavaScript executes our programs sequentially, statement by statement. JavaScript engine blocks the execution of the next program until our current program is completed. Does not matter how long our program is taking to complete, JavaScript would never bypass our program, thus blocking the rest of the code.

Dual Faced JavaScript

Well at some points of your research, you might have also encountered somewhere something like;

JavaScript is asyncronous in nature.
JavaScript is non-blocking programming language

Now see what this means actually;

Asynchronous: JavaScript is asynchronous means, it does not wait for a program to complete if it is taking too long, it simply bypasses it and moves to the very next program.

Non-blocking: Similarly, JavaScript doesn’t block the execution of our program if our current program is taking longer. JavaScript parks our guilty program and moves to the next program, thus non-blocking in nature.

Which JavaScript face is the correct face?

Well, let's clear our confusion. JavaScript is synchronous and asynchronous at the same time. Well, no doubt, JavaScript is synchronous by default. But that doesn’t mean you cannot run it asynchronously. We can make JavaScript run our code asynchronously by using various means. Which we will be discussing in a short while.

Synchronous JavaScript

I am pretty sure you are already well aware of the synchronous face of JavaScript, well we will be talking about Asynchronous JavaScript in this guide. Consider this very simple program which is handled synchronously(default behavior);

This program logs everything in sequence,

Program Start → Function Start → Function End → Program End

You are already well aware of this behavior so we will not be wasting any time on this.

Guide Outcomes

I follow along me, at the end of this article you will be able to answer all of these questions.

What is Asynchronous JavaScript? And why do we need asynchronous JavaScript?
How do we implement Asynchronous JavaScript in our code?
What are Web APIs? And what Web APIs can be helpful in writing Asynchronous JavaScript code?
What are callback functions? And we can write asynchronous code with them?
What are Promises in JavaScript? And what is their role in modern asynchronous JavaScript?
What are the microTask queue and the Callback queue in JavaScript?

What is Asynchronous JavaScript? And why do we need asynchronous JavaScript?

As we already know JavaScript is synchronous in nature by default. It executes every program sequentially and blocks the next program until the completion of the currently executing program.

But, What if we need do not need to run our code immediately? We need to park our function to be executed in the future under specific conditions.

What if our program takes a bit longer to complete? Our complete program would freeze until its completion.

What if our program needs some external data, and makes an API call to the server? Of course, depending on the speed of the server, it would take some time to receive a response from the server.

I can give you many scenarios, which make asynchronous JavaScript necessary.

How do we implement Asynchronous JavaScript in our code?

We can write asynchronous JavaScript logic in our program in a number of ways. Modern JavaScript and Web browsers provide us with these major means to write asynchronous JavaScript code;

Web APIs
Callback functions
Promises (replacement of callback functions)

Web APIs

To understand Web APIs properly, we need to know little behind-the-scenes of javascript. For those who do not know, our browser is the place where JavaScript code is executed. Our browser provides our code with a special environment called the Runtime Environment. Runtime environment actually comprise four major components;

JavaScript engine
Web APIs
The Eventloop
The callback(task) queue

If you want to learn more about JavaScript Runtime Environment and working of JavaScript behind the scenes, Check out my extensive guide on Working of JavaScript under the hood.

Here our main concern is Web APIs. JavaScript runtime environment exposes our code with some extra features provided by the browser client. We can use these features in our application to gain extra power.

Common Asynchronous Web APIs
If have been using JavaScript for a while now, you must be already aware of the popular Web APIs like the DOM API, fetch API, and the Canvas API. You can check the complete list of popular Web APIs here.

Here, we are only interested in asynchronous Web APIs, like the fetch API, setTimeout(), setInterval(), etc.

Consider this example where we are using fetch API to load resources from the server asynchronously. Let's assume our request is gonna take 1 second (1000ms) to return a response.

First I want you to guess the output in the console. If you guessed;

Program Start → Function Start → Program end → 1000ms Delay → Fetch call response → Function End

You are right. What will be the output of this code, if the fetch API was synchronous? Here.

Program Start → Function Start → 1000ms Delay → Fetch call response → Function End → Program end

We can clearly see that our fetch call to the server was handled asynchronously because we are using a special fetch Web API. Our program starts, call to the server is initiated. But instead of waiting for the server to return some response, the JavaScript engine moves to the next statements. Even it jumps out of the getPosts function.

We can use other Web APIs like setTimeout, and setInterval to create timer functions that will run after a specified time period. Will run once in case of setTimeout and periodically in a loop in case of setInterval. We will not deep dive into them for now.

Callback functions

The callback function is just a normal function that is passed to another function as an argument, and the execution of our callback function is handled inside and by the parent function.

First of all, keep in mind that both the functions involved are just normal JavaScript functions. As functions are also objects like most of the stuff in JavaScript, we can pass them to other functions as arguments.

Our callback function doesn’t get executed right away, but it is gonna sit and wait until parent functions call when it’s needed. This way we can separate some logic in a function and park it outside of the main execution thread. This way we can shift JavaScript from synchronous blocking to asynchronous non-blocking.

Here is a small catch. Callbacks function can be synchronous or asynchronous. Synchronous callback functions are invoked immediately inside outer functions, but asynchronous functions sit and wait until the specific condition(s) are fulfilled in the future.

Consider this simple example, where we are passing the greeting function as an argument to processUserInput function. That is called when the user inputs his/her name in the prompt. Our callback function also accepts an argument (name), which is provided by an external function. Now, you need to guess, whether it is synchronous or asynchronous.

Of course, it is a synchronous callback function. Our callback function is being called immediately in the external function. Well, you might say the user will take some time entering the name, then how it is immediate execution? Well answer to this is very simple. The delay is from the user itself. If you see our program, there is no programmatic delay. As soon as there is an input, our program invokes the callback function.

Let's make the above example asynchronous. Now we have added setTimeout Web API, which creates a timer function inside the browser and invokes our callback function after the 2-second mark.

This is an example of the asynchronous callback function because we are parking our callback function using setTimeout Web API. I can prove it by the output of this program. When you run this program, you see;

User {name} input → setTimeout() executed → Callback function bypassed → 2 Second Delay → Hello, {name}

In traditional JavaScript, we used to handle our asynchronous logic using callback functions. This is the reason you might see some old StackOverflow answers(i often do need them 😆) using callback functions, and sometimes callback hells.

Callback Hell

As we know, we pass the callback function to another function to complete its execution inside the parent function. What if we do not need our parent function to be called immediately, but inside another function? Well, another function. Is it a problem? Nope, it's totally fine.

But what if we need to pass control of our second parent function to another function, by passing it to another function? Is it a problem now? It looks messy but no problem. I can handle it. Okay!!! fine.

But what if…. Hey hey, stop 🛑. It is a problem. A big problem indeed. Give me the solution.

The solution to this messy callback chaining was introduced in ECMAScript 2015(ES6). JavaScript introduced more descent and performant way to handle asynchronous code in the form of promises.

JavaScript Promises

The callback function approach is really effective in small programs, with up to 2 to 3 levels of chaining. But beyond that code becomes like a hell to read.

JavaScript introduced a very cleaner, more performant, and more elegant way to handle asynchronous behavior in our code.

Promises are JavaScript objects that can have one of the 3 possible states, depending upon the outcome of the promise.

Pending
Fulfilled
Rejected

Promises in JavaScript are no different than promises we make in our life. Like real-world promises, JavaScript promises can be kept or rejected. You make a promise for something in the future, let's say you will quit smoking. With the passage of time, there are two possible scenarios;

A promise is fulfilled: You successfully stand by your promise and the promise is kept. In the context of JavaScript promise, the promise object returns some data.

Promise is rejected: You are not able to fulfill your promise and get rid of the promise instead of smoking😍. In the context of JavaScript promise, on rejection, the promise returns some error.

Hopefully, this far you understand the basic soul of Promises in JavaScript.

I was reading the guide on Promises on W3Schools and saw something really explanatory.

“Producing code” is code that can take some time.

“Consuming code” is code that must wait for the result.

A Promise is a JavaScript object that links producing code and consuming code.

Let me show you what this means with examples. You encounter two scenarios while dealing with Promises in this world of JavaScript.

Creating Promise — “Producing code” is code that can take some time.

Let's create a simple promise, that takes 2 seconds to complete and returns some data if resolved and an error if rejected. This is how we implement this;

What is happening here;

Step1: We create a new promise by using new Promise() , and assigns it to myBasicPromise variable.

Step2: We are faking the time factor by 2 seconds by using setTimeout Web API, to pretend our promise actually took some time to complete.

Step3: After the 2-second mark, data is available(from API call, from a local file, etc.).

Step4: Hard part, we resolve or reject our promise based on performing checks on the data we retrieve.

Keep one thing in mind that, when you are using JavaScript, you will rarely need to create promises, but consume in most cases. All of the latest libraries, modules, and features come with built-in a promise-based approach. Like, fetch API, axios client, File API, etc.

Consuming Promise — “Consuming code” is code that must wait for the result.

Let's consume our promise. Wait. There are two approaches that we can use to consume promises.

then() — catch() methods
async / await keywords
Let's start with the first method.

Using then() catch() methods

What is happening here;

Step1: If the promise was resolved(fulfilled) after checks we make on data, we get result inside then() method. We can do anything with this response data.

Step2: If the promise did not pass checks and was rejected, then() method is skipped altogether and we catch errors inside catch() method.

I have added the last console statement so you can see, that this statement will always run before the promise result or error. Shows us that promise runs asynchronously and doesn't block the preceding code. Well, there is another method attached to the promise object called finally(). I forgot to add it in the screenshot. You can add it after the catch block, and it will always run when the promise has been settled(resolved or rejected.)

Using async / await keywords

We can consume our promises using async await keywords as well. Here is how.

Step1: We are wrapping our promise-consuming logic inside an async function, so we can use await keyword. Awaiting our promise object returns us results if the promise was fulfilled. This step is similar to using then() method in the above approach.

Step2: But what if our promise was rejected? How do we catch error in this case? We can use JavaScript special try{} catch{}. It will try to execute our promise, but will also catch any error which pops out during the process. Remember that, try{} catch{} blocks are not specific to promises, but they are general JavaScript features that we are using in this approach.

Promise Chaining

Let's discuss the main reason, why we should use Promises over callback functions. Callback chaining(callback hell) was the main reason we adopted Promises, now we need to do the same thing in Promises.

You can easily chain a series of actions simply by using multiple then() methods. We will discuss the promise-based implementation of fetch API.

Using chaining then() methods

As you can see, we are not producing code here, meaning we are not creating a promise. We are just the consumers, as you will be in most of cases.

What is happening here;
Step1: We are fetching posts from JSON placeholder API. When we call fetch(API_END_POINT), it returns us a promise object. From here we can handle our promise by using the then() method.

Step2— First then(): We receive a response inside first then() block, when fetch() promise, was resolved — successfully fetched. We might encounter an error as well inside the catch() block, due network problem, or in case the server responds with the error.

But why do we need chaining in this particular case? The reason is that fetch API returns the response object in the first place. But we need data instead. This response object, holds the json() method inside its prototype(__proto__) property. We call the json() method on the response object, which in turn returns use another promise. Which can be handled inside first then() block, or we can chain then() blocks.

Step3— Second then(): Keep in mind that, this particular then() method is not attached to the main fetch() promise. But the promise returned by then() just behind it. Once res.json() promise resolves, we get our data. We have retrieved our data, so need to further chain promise.

Chaining using async/await methods

I am not going to explain this time. The guide's length has already grown more than I expected. I believe you already know it.

BONUS
As you can see, the fetch() promise accepts an argument. So let me tell you, how you can pass arguments to your promise.

Simply wrap your promise inside a function, and return the promise from it.

Final Step

To completely understand asynchronous code behavior in JavaScript we need to address the final question.

What are the microTask queue and the Callback queue in JavaScript?

Well, to understand these concepts we need to know little about how the JavaScript engine executes asynchronous code. Whenever Promise, Web API, Mutation Observer, etc. are encountered inside our code. It is added to the Callstack. As we do not intend it to be executed right away, it creates a sort of timer function and pops out of the main execution stack.

Once the timer function has expired, our callback function(function passed to then() or function passed to setTimeout(), etc.) is sent to one of the Callback queue or the microTask queue.

Callback functions from Promises, Mutation Observers, and fetch API has higher priority and goes to the microTask queue.

Ordinary callback functions from Web APIs like setTimeout, and setInterval go to the callback queue.

The MicroTask queue always has higher priority, and eventloop will always check for the callback queue once all of the callbacks from the microTask queue have been transferred to the Execution stack already.

You can learn more about the MicroTask queue and the Callback queue from this awesome article at geeksforgeeks.

Wrapping Up

Hopefully, you liked this guide, and let me know if something was confusing in this entire guide. If you find some mistake, please let me know. I would love to make the correction for future readers.

I regularly post guides like this, about the MERN stack. If this is your field of interest and want to read other guides like this, do follow me.

See ya soon. Till then stay safe and try to keep others safe. ❤️

SSR - SSG - ISR - CSR in Next.js - The Ultimate Guide

Azhar Dev — Wed, 03 Aug 2022 09:42:00 +0000

Are you a React lover? If you ask me, of course, I am a die-hard fan. Performance boost, virtual DOM(vDOM), and Components-based architecture were the major factors that convinced me to choose React.js over other awesome JavaScript frameworks in the market, like Angular and Vue. Without a doubt, the main reason users go for React is the performance boost it gives against traditional technologies. Without a debate, ReactJs is an awesome library that gives us a massive performance boost using vDOM and unlocking something called Client Side Rendering(CSR).

You might also have heard of Next.js, of course. Next.js is basically the hottest React.js framework in the market right now. And my personal favorite as well. If you are coding in React for some time now, I bet you have heard of it and some lucky fellows might have tried it as well. Please let me know your experience in the comments section after reading this guide.

Well, guys at Next.js claim that;

The React Framework for Production!
Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more. No config needed.

After reading the above statement, a lot of questions arise in our minds, if nothing came to your mind, I am really sorry 😉.

Questions like;
Is NextJs better than Vanilla React?
What does NextJs provides us, which ReactJs don't or can't?
If React is a beast performance considering performance, why do we actually need NextJs?

You will get all of your answers in this guide. Just stay with me. We will answer these questions one by one.

Is NextJs better than React?

Without a debate, NextJs has a significant edge over React in production. One of the reasons is obvious that it is an extension, a sort of wrapper of React. NextJs provides us with all the features of React and in addition unlocking some major features like Server Side Rendering(SSR), built-in API routes, automatic Code Splitting, assets optimization(fonts, images, etc.), pre-rendering, and much more.

The main focus of our today's tutorial would be pre-rendering in NextJs, different ways of pre-rendering, like Static Site Generation(SSG), Server Side Rendering(SSR), and something really cool, Incremental Static Regeneration(ISR).

ISR is basically an advanced version of SSG, which we can use to tackle stale(outdated) data problems in SSG. We will discuss automatic ISR as well as how we can manually trigger revalidation.

What does NextJs provides us, that ReactJs do not or can not?

As we have already discussed, NextJs provides us with all the features of React and in addition unlocking some major features like Server Side Rendering, built-in API routes, automatic Code Splitting, assets optimization, pre-rendering, Internationalization, and much more. For a complete reference, do visit the Next.js homepage.

If React is a beast, why do we need NextJs?

Well, this important question needs to be answered in detail. We need to know how React.js works, and what improvements Next.js does bring to the table.

Working of React

Before React, some smart minds at Facebook noticed that JavaScript was pretty fast but DOM manipulations were slowing everything down. DOM is basically an object-based representation of the Web page we are viewing. DOM is a set of nodes, every node refers to a particular element on the webpage. In short, DOM is a tree-like object-based representation of a document, which contains information about a particular element, styles associated with that element, the geometry of that element in the document, etc.

Before React, when we needed to change something in a webpage (DOM - behind the scenes), the whole webpage was recreated. This was very unintelligent and expensive. So programmers at Facebook came up with a smart(actually genius) way of manipulating DOM.

The problem was a recreation of the whole DOM when the small change was to be reflected on the webpage.

And the solution React.js brought was intelligent monitoring of the actual dom in form of virtual DOM(vDOM), and only updating necessary portions of the actual DOM in the best way possible.

This gave a massive performance boost compared to traditional DOM manipulation techniques as well as modern React competitors like Angular and Vue.

Client Side Rendering (CSR)?

React.js also unlocks Client Side Rendering. Let me explain What CSR is? And how React.js uses CSR to provide us with performant applications. When a user visits an application built with React, following processes occur behind the scenes;

[Image copied from this awesome article by Alex Grigoryan]

Step1: Almost empty response is sent to the client(browser), which is a minimal HTML document. This document has nothing in it except links to the JavaScript chunks sitting on the server. There is a little blink of emptiness before the web page is fully visible because there is nothing to render, but an almost empty HTML document.

Step2: In the second step, the JavaScript bundle is downloaded from the server. Usually, a complete application bundle is downloaded unless manual code splitting(React.lazy()) is implemented.

Step3: Browser executes JavaScript (React), and renders(createRoot(rootEl).render()) content to the screen. Populates empty HTML document containing root node. At this point, our page is completely visible and interactive.

On the other hand, Next.js does these things a little differently. Here is how.

Working of Next.js (SSR)

Next.js unlocks Server Side Rendering (SSR) for our applications. In vanilla React.js we can implement SSR components as well using something called ReactDomServer, but it requires a little extra configuration.

In Next.js(SSR), a request is sent to the server for a specific page, instead of sending the whole JavaScript bundle to the client, the server itself takes responsibility of rendering the page for us.

[Image copied from this awesome article by Alex Grigoryan]

Step1: First of all after the request hits the server from the client, it starts building an HTML document for us. These powerful servers with extremely fast internet (for instance Vercel) can do this task in milliseconds.

Step2: Freshly generated HTML page is sent back to the browser with some associated JavaScript necessary for the page. The browser takes the HTML document and displays it for us. At this point, the page is completely visible to the user. But unfortunately, users cannot interact with it. But here is another catch. This phase of numbness does not last any longer than a few milliseconds.

Step3: Then comes the hydration part, the browser downloads JavaScript from the server, and now Page is interactive as well.

Difference

Page is visible faster in the case of Next.js than React.
There is a little blink in the case of React because an almost empty document is received by the browser at first. While in the case of Next.js fully rendered HTML document is sent to the browser, so no blink.
Server resource utilization is usually high in the case of Next.js because the server is the one doing all of the heavy duty.
Overall performance is high in the case of Next.js because only necessary stuff(automatic code splitting) is downloaded from the server instead of the complete application bundle as in React. Readymade page is sent, ready to render the page is sent to the browser.

As it is evident now, Nextjs has an edge over React js in almost every aspect. So it is not even a debate. Enough of the comparisons, let's focus on our main topic for today.

What is pre-rendering?

Next.js pre-renders every single page by default on the server. When a user requests a page from the server, a page is freshly built(SSR) on the server or the page is already sitting on a server(SSG), ready to be delivered to the browser. We will discuss all the possible scenarios. This technique adopted by Next.js, to send ready-made, ready-to-render pages to the browser when requested is called pre-rendering.

If you visit Next.js pages documentation, you will learn that Next.js pre-renders every page, by default.

By default, Next.js pre-renders every page. This means that Next.js generates HTML for each page in advance, instead of having it all done by client-side JavaScript. Pre-rendering can result in better performance and SEO.

Next.js don't believe in Client Side Rendering, which puts everything on the user's CPU and internet to make our application run. Instead, Next.js handles rendering Server side. Next.js pre-renders(pre-builds) every page in advance before it is sent to the browser(SSR), or even before the page is requested by the user(SSG).

Next.js generates HTML documents for every page on the server in advance, associated with minimal JavaScript necessary for the page. Our web page is completely available to the browser as well as search engine crawlers. Which in turn gives us better SEO scores and performance.

We need to address some questions that might have already popped into your head. Questions like;

How does Next.js handle pre-rendering pages?
What types of pre-rendering are there in Next.js?
When to use, what type of pre-rendering?

How does Next.js handle pre-rendering pages?

NextJs pre-renders every page by default. When we bootstrap the Next.js app, we get /pages directory. Any file inside the pages directory is mapped as a page if it default exports a function.

Create Next App

Let's create an empty Next.js app using create-next-app, so you can also follow along. Open your terminal, and run the following command;

npx create-next-app@latest <app-name>

Or with yarn

yarn create next-app <app-name>

Do not get confused by npx here, as npm and npx are two separate things. npm is a package manager for Node.js. While npx is a package by npm, it can be used to run npm package binaries.

After finished, open the directory in the code editor, and spin up the app in the dev environment by running npm run dev or yarn dev.

Our main focus will be on the pages directory, so open it. You will see:

/pages/api: Next.js provides us a way to build API routes from within our Next.js app in the form of serverless functions. As Next.js is using Node.js behind the scenes. We will discuss this in a while.

_app.js: This is pretty much the starting point of every page inside the page's directory. You can think of it as a wrapper for every page.

index.js: This file represents the homepage of our application, which users will see the visiting the root of our application, let's say, www.example.com/.

Well, we can add new pages inside our application by simply default exporting a component from a file inside the pages directory. Let's say we want to create an about page for our application, simply add about.js inside the /pages directory. Now you can visit your page at localhost:3000/about.

What types of pre-rendering are there in Next.js?

As we already know Next.js builds every page in advance before it is sent to the browser. But we can categorize pre-rendering on the base of the time when the page(HTML document) is built on the server.

Next.js supports two kinds of pre-rendering at the moment. But we can leverage it to three as follows;

Server Side Rendering(SSR)
Static Site Generation(SSG)
Incremental Static Regeneration(ISR) - SSG extension

Server Side Rendering?

If a page is being generated again and again on every request, then it is Server Side Rendering. SSR is a great option for applications that need to update the UI more frequently, like stock listing applications. The user comes to the page, the request is sent to the server. The server generates a fresh copy of the Webpage(HTML document) and sends it to the client with minimal JavaScript associated with it.

After the page has been painted(displayed) by the browser, the browser downloads JavaScript and makes the our page interactive. This is called hydration. I will not discuss hydration in detail here, but Hydration is basically a process when our browser downloads JavaScript from the server, and the page becomes interactive. You can learn about it more in this article.

How to implement SSR in Next.js?

Well, another plus point of Next.js is that it gives you complete control over your application and does not bind you to use SSR or SSG for your entire application. You are free to choose SSR or SSG for individual pages. Or even you can use SSR or SSG on some portion of your page and then use Client Side Rendering(CSR) at runtime to handle the rest of the page. We will discuss these use cases in a while. For now, let's see how we can enable SSR for any page in Next.js.

Consider this home page, fetching and listing fresh stock quotes every time this page is requested;

Step1: Replace the content of the homepage /pages/index.js as;

By default, Next.js pre-renders this page via the Static Site Generation(SSG) technique. If we need to enable SSR on this page, there is only one thing we need to do. I mean this is the beauty of Next.js. We enable Server Side Rendering by just exporting a special function getServerSideProps from our page.

getServerSideProps

This is a special function provided by Next.js to unlock SSR for our page. If our page is exporting this function, the server will pre-render our page prior to sending out the page to the client. This function runs on every page request received by the server. If this page is requested by a transition in our page via next/link our next/router, an API request is sent to the server which triggers getServerSideProps. Head over to this page to see the complete getServerSideProps API.

Step2: Export the async function getServerSideProps from our application.

Step3: Fetch fresh data from a data source(API, database), and return an object containing props as a key.

By doing these simple steps, we have implemented SSR in our application. We will now receive our data inside the props object of our page. As getServerSideProps runs, every time page is requested, we get fresh data from our data source. And every time up-to-date data is displayed on the webpage.

Static Site Generation (SSG)

The second and recommended form of pre-rendering is Static Site Generation. As evident from the name, it is the best use case for static web pages which can be built before request.

In the case of SSG, pages are built on build time when we build a site using next build on the server. These pre-built pages sit on the server and once a request is received, these pre-built pages(HTML document and minimal JavaScript associated) are sent to the browser. Once the page has been painted in the browser, JavaScript is downloaded and the page becomes interactive after hydration.

Pages built with SSG can also be cached via CDN unlike pages built using SSR. So response time is significantly low compared to SSR. Gives better performance and SEO score.

How to implement SSG in Next.js?

Well, Next.js by default pre-renders pages statically using SSG. So no extra configuration like getServerSideProps (in case of SSR) is needed if your page doesn't depend on external data. Well, we can pretty much encounter three scenarios while statically generating pages in Next.js.

Scenario1: No need for external data while building a page on the server. If you are building some static website like a portfolio website, Guide, or Documentation site, usually(not always) you do not require any external data.

In that case, you can simply default export your React component from the page file and you are good to go. Simply like this.

Scenario2: Your page needs some external data to be built on the server. Well, if you are building some product listing page or any page that needs data from an external source to be properly built on the server. Consider this about page, which needs to fetch team members from some database. Of course, the server cannot build a page without data being available first.

How do we handle this case? Don't worry, it's not difficult. Next.js provides us with another special function named getStaticProps. We can simply export it from our page and fetch data in it prior to pre-rendering.

getStaticProps

It is a special function, provided by Next.js to help us fetch data prior to pre-rendering. This function runs on the server, so not included in the client-side bundle. It runs before building the page and passes data to the page via props. Head over to this page to see the complete getStaticProps API.

Scenario3: Your page is dynamically generated, and your page also requires data from some external data source. Consider the case of a blog or e-commerce website. Where you cannot create an individual page for every blog post or product inside your page's directory. You need some more automated way to accomplish this task. Let me show you how you can handle this case in Next.js using SSG.

We are going to use something called dynamic routes in Next.js. We will move forward with a blog example.

Implementing Dynamic Route

In Next.js, we can create a dynamic route with a special syntax. We need to add /pages/blog directory, inside that we need tocreate two files; index.js for posts archive and [slug].js for individual post pages.

With syntax done, any path after localhost:3000/blog/ will be available to us for use inside [slug].js via router object. I will show you in a while. I will show you in a while. You can learn more about dynamic routes over here.

Fetching data for a specific post using slug parameter

I believe you have already guessed it. We will simply export getStaticProps from our file. But this time, the requirements are a bit different. Last time we knew what exactly to get from the data source.

This time, it's a dynamic route. Actually, we need to fetch data from the server based on a slug. Like in this case /blog/post-1 we need to fetch post with slug=post-1 and in case of /blog/some-other-post-slug out slug would be different. some-other-post-slug exactly.

Next.js makes our work a bit easy and provides us what is the slug of the requested page inside getStaticProps.

Add getStaticProps to fetch specific post by slug;

Once a post has been fetched we are passing that data to the PostPage component as props. We are checking if the post is not defined, and we are returning a notFound=true This will ensure a 404 page appears if the post was not there.

Well, you might be thinking, that's it like previous cases. But it is not the case this time. Because we are pre-rendering blog posts dynamically. Now think about it, how would Next.js know which blog posts to pre-render? There could be many blog posts and we want to pre-render all of them. The answer is we need to tell Next.js that, these are the routes(slugs), that needed to be pre-rendered.

What Next.js would do is, just run getStaticProps props for every slug we will provide. It will fetch data from the data source and pre-renders page for us. Now the question is how do we tell Next.js, which routes to pre-render?

This is very simple, as Next.js provides us with another special function called getStaticPaths that we need to export from the dynamic route page [slug].js.

getStaticPaths

getStaticPaths is a special function provided by Next.js. It runs on the server only, so addition to the client bundle. This function runs only once on the server to supply Next.js with the list of paths that need to be pre-rendered. Head over to this page to see the complete getStaticPaths API.

Simply export the async function getStaticPaths from our file. Now logic from here may with your use case. But let me tell you, what you have to do actually.

Step1: Fetch all posts of just slugs(if query filtering is available in your use case)

Step2: Format slugs or posts to a specific pattern. Where paths is an array of objects, each object containing single key named params, with an object as the value. This object contains the key named after the query parameter you used in the dynamic route file name. In my case, it is slug.

See the below example.

If you followed along, you have successfully implemented Static Site Generation in case of dynamic routes using getStaticProps and getStaticPaths.

Caveats in Static Site Generation(SSG)

So far we know that pages generated using the SSG technique give us better performance and high SEO scores. Also, pages built with SSG can be cached via CDN so users can get responses even faster. These are all the plus points of SSG. But there is a catch here.

We know that pages are built at build time in SSG. But what if a user is accessing the page after several months? What if data on the CMS has changed? Admin has made some updates. What data would be displayed on our page? Same outdated data, right?

This behavior is not needed in a few cases, where data gets updated more often. How Next.js handles this case scenario. Well, I am going to introduce Incremental Static Regeneration(ISR) to you. I have recently built my personal blog using Next.js. And it is also using Incremental Static Regeneration.

Incremental Static Regeneration(ISR)

ISR is an awesome technique introduced by Next.js to tackle stale or outdated pages problems in Static Site Generation. It is not another kind of pre-rendering technique but an extension of SSG actually.

You need to know what we are actually trying to solve here. We want our webpage to show updated content when we update data in the backend. When data you updated data in the backend, probably CMS, then you have 3 ways to update content on the Frontend (Next.js).

Method1(NOT RECOMMENDED): You can re-build your entire application(excluding cache) again when you need your page or pages to show updated data.

Method2: You can use periodic ISR (I named it myself 😍).

Method3: Or you can use on-demand ISR.

We will discuss both of these. Let's start with periodic ISR.

Periodic Incremental Static Regeneration

This type of ISR automatically rebuilds our page(not the entire application) after a specified time period, when a request comes after that specified period.

Let me explain. When users land on the page, a counter starts. Our user is seeing our cached version of the webpage. So performance factor is not affected. Our user gets the same page that a user would get if ISR is not implemented.

When a counter hits our specified time, a request is sent to the server to rebuild the page. Everything is happening behind the scenes, in the background. Any request after our specified time, Next.js serves the newly built page. And this freshly prepared page is cached again. Again the cycle begins.

Let me show you periodic ISR in action;

You just need to add revalidate prop inside the getStaticProps function of your [slug].js file. Next.js will try to revalidate(rebuild) our app when a request comes in after 60 seconds.

Mean, for the first minute out user will see, the same cached version of our page and any request coming after one minute window will trigger revalidation on the server. Next.js will rebuild the page in the background. If a page was built successfully, Next.js will invalidate the cache and show an updated page afterward.

[NOTE: 60seconds is too aggressive. Your server resources will be under fire when it needs to rebuild your page every minute(at most), Either you should use on-demand ISR or keep time as high as possible.]

On-demand Incremental Static Regeneration

I personally like this type of ISR, because you have kinda more control over revalidation. You decide when you want to revalidate your page. Your server resources are safe. This also minimizes the period, when users need to see outdated pages.

To implement on-demand Incremental Static Generation, we simply need to create an API route, which we can later call to revalidate particular paths.

I hope you already know how to create API routes in Next.js. But if not, I will explain in a beginner-friendly manner. Or you can simply head over to this guide to have a sneak peek.

Implementing revalidate API route

We do not need to provide extra revalidate prop inside getStaticProps. So make sure to remove what (revalidate: 60) we added in the previous example.

Let's create our API route. Add file inside the /pages/api directory. In Next.js file added inside the /pages/api directory is mapped as an API route, and can be accessed at localhost:3000/api/some-route.

We have added a basic handle for our route. You can test this by running running localhost:3000/api/revalidate. You should get a JSON response back.

Let's configure our handler to revalidate our page.

Step1: Grab the token and route from our request. While trying to revalidate, we would need to provide the route we want to revalidate and a secret token(prevent unauthorized requests) inside the request URL.

Our sample request look will look like this;

In production

GET https://<your-site.com>/api/revalidate?secret=<token>&route=<route>

In Development

GET http://localhost:3000/api/revalidate?secret=<token>&route=<route>

So first thing first, let's add our secret token inside the .env.local file. This is the place where we can store our environment variables in Next.js.

Kill and restart your development server. You should be able to see environment variables loaded message in the console.

Step2: Secondly we need to do certain checks. First of all, if a token is not defined or the token inside the request and the one inside .env.local does not match. Return server error with status code 401.

Secondly, if the route is not defined, we need to return the very same response but with a different message.

Step3: Inside try catch block, we try to invalidate our route by calling res.revalidate(route) method. And once it is done we return a successful response. If any exception(error) occurs, we catch it and return an error response with a status code of 500.

That is it for revalidate API handler. Now our API route should be working fine. Time to test it out.

Testing

Open your browser and enter make a request to the following endpoint;

http://localhost:3000/api/revalidate?secret=<token>&route=<route>

Replace <token> with your own secret token inside .env.local and replace <route> with your slug prefixing with /blog/.

For instance, if you want to revalidate /post-1 and your token is 123456789. Then your request should look like this.

http://localhost:3000/api/revalidate?secret=123456789&route=/blog/post-1

If you get success response, with revalidated=true . You have successfully revalidated your page.

Conclusions

In this guide we have learned;

What is Client Side Rendering and how does React.js use it?
Why do we need to use Next.js instead of React.js in production?
What is pre-rendering and how does Next.js handles pre-rendering our pages?
How many kinds of pre-rendering are supported in Next.js?
How to unlock Server Side Render your pages in Next.js on every request(SSR)?
How to statically generate web pages in Next.js at build time(SSG)?
How to solve stale data problems in pages build with SSG using Incremental Static Regeneration?
How to periodically revalidate your pages, and how to implement on-demand Incremental Static Regeneration?

Wrapping Up

Hopefully, you liked this guide, and let me know if something was confusing in this entire guide. If you find some mistake, please let me know. I would love to make the correction for future readers.

I regularly post guides like this revolving around the MERN stack. If that is your field of interest and want to read other guides like this, do follow me.

See ya soon. Till then stay safe and try to keep others safe. ❤️

0 to 1 - How JavaScript works under the hood (Part 2)

Azhar Dev — Fri, 22 Jul 2022 06:51:49 +0000

Hi, welcome back.

If you are coming from part one of this guide you will find this part a breeze. But if not, I will strongly recommend you to check out Part 1 which serves as a base for this guide. But you can also read and gain something from this article alone. This guide is completely independent of the previous one.

So far we have learned in Part 1

A little history of JavaScript
JavaScript Runtime, which is basically a special environment provided by the browser or context we run our code in. This environment provides us with objects, APIs, and other components so our code can interact with the outside world and get executed.
Components of runtime environment; like JavaScript engine, Web APIs, Callback queue, and Eventloop.
JavaScript engine, which again consists of Callstack or Execution Stack and the Heap.
Execution Context, which is basically a special environment for the execution of JavaScript code, contains the code that is currently running and everything that aids in its execution. This special environment is called the Execution context.
Scoping and Temporal Dead Zone, we learned how functions can access declarations from their parent scope via Lexical Scoping. We briefly discussed TDZ as well.

In this article, we will be focussing more on the remaining three major components of JavaScript runtime in the context of the browser;

Web APIs
Callback queue
The Eventloop

The drawback of JS single-threaded nature

As we all know JavaScript is single-threaded in nature, as it has only one heap and one stack. The next program has to sit and wait until the current program finishes execution, heap, and Callstack get cleared and the new program starts executing.

But what if, the currently executing task is taking so long, what if our current execution context is requesting some data from the server(slow server), definitely it would take some time. In this case, the Callstack queue will be stuck as JavaScript only executes one task at a time. All the execution contexts that are next to be executed will keep waiting until our current guilty Execution context is resolved. How we can handle this sort of behavior. How can we schedule some tasks, or park some expensive tasks so that we can keep our application going? How can we make our synchronous JavaScript asynchronous?

This is where Web APIs, Callback queue, and Eventloop come to the rescue.

Web APIs

First of all, we should know that Web APIs are not part of the JavaScript engine, but they are part of Web browsers. They provide our code with some extra features so our code can interact with the outside world. Modern web browsers have a lot of web APIs which we can use in our applications. We often use web APIs to carry out these noble purposes in our application:

Dom Manipulation: Probably the most commonly used web API among JavaScript developers is the DOM API which enables us to manipulate DOM and CSS styles associated with DOM elements. It gives us the power to add nodes to DOM, remove them or apply styles to them dynamically.

Graphics Manipulations: Web APIs like Canvas API and Web Graphics Library API let you draw and manipulate graphics in the canvas element. They let you programmatically add or modify graphics. The Canvas API provides a means for drawing graphics via JavaScript and the HTML <canvas> element. Among other things, it can be used for animation, game graphics, data visualization, photo manipulation, and real-time video processing. The Canvas API largely focuses on 2D graphics.

Asynchronous JavaScript: As we already know originally JavaScript is single-threaded synchronous in nature. But we can make it asynchronous with Web APIs like XMLHttpRequest and its promise-based replacement, the Fetch API. We can enable our JavaScript code to carry out other vital tasks until a response from the server is returned. We will talk about asynchronous JavaScript more in a while. For now, let's just move forward.

Work with Multimedia: Web APIs like Audio API and HTMLMediaElement provide us control over audio and video on the web. We can pause, play, forward our media or add certain effects to the stream.

Work with Files: The File API enables web applications to access files and their contents. Web applications can access files when the user makes them available, either using a file <input> element or via drag and drop.

All of the event listeners, AJAX calls, and timer functionalities sit in the Web APIs container until an event is triggered.

Before deep diving into the Callback queue, we should first discuss Callback functions.

What are Callback functions?

The callback function is a normal function provided as an argument to another normal function, waiting to be called inside the recipient function at a suitable time.

Let me explain it to you. The callback is not a special kind of function. It's just a normal function that is passed to some other function, and that function handles the invocation (calling) of our callback function. See this Callback function supplied to click eventlistner;

As you can see we are providing a callback function to the listener. This function is not called right away but when a click happens. So the callback function is sitting and waiting somewhere in the JavaScript engine for its trigger. When a user interacts and clicks, this function gets called. So the place where this function is sitting and waiting is the Callback queue.

At first callback functions were used to handle asynchronous tasks in JavaScript. They did pretty well but handling more complex became like a hell. Because when a callback function is also an asynchronous function and receives another callback, syntax became really messy which we call The Callback Hell these days.

Well, that is not our topic for today, you can check out callbacks here.

The Callback Queue

The callback is a data structure that holds callback functions sent by Web APIs. Callback functions sit here until the Callstack is empty, and the Eventloop transfers them to Callstack.

As we all know JavaScript is a single-threaded synchronous language natively, and It runs your pieces of code sequentially. Line after line. If Line 13 is taking longer than expected, our program would freeze and would not attempt to execute Line 14 until 13 is completed. This is the problem that the Callback queue solves. Have a look at this setTimeout Web API:

setTimeout Web API executes a provided callback function after specified time. Learn more about of setTimeout here.

If we consider JavaScript as a single-threaded, synchronous programming language what output we would expect from this above code:

Expected

First of all, 1 will be logged to the console as a result of console.log(1).

Then, after waiting for 1 second (1000ms), the callback function will be executed logging 2 to the console.

And finally, the program will end after logging 3 to the console as a result of console.log(3)

Output

First of 1 logs as expected.

Unexpectedly, 3 logs to the console next. Apparently, the JavaScript engine skipped setTimeout and moved on to the third statement console.log(3).

Then after 1 second 2 logs to the console.

Explanation

Let me explain this behavior; at first, JavaScript encountered the console.log() function and stored it in the Execution stack or Callstack for execution. Functional Execution Context(FEC) gets created to execute this special built-in function(method), and it gets executed and fades out of the Callstack.

Secondly, as a second statement, the JavaScript engine encounters setTimeout Web API. As we all know, setTimeout is not a feature of JavaScript itself. First of all, setTimeout is added to Callstack. But it is not executed here, being a web API, it creates a task inside the browser and pops out of the Callstack.

JavaScript engine keeps executing code, again encounters console.log(3) function and creates Functional Execution Context to handle it. Very similar to statement 1 console.log(1) it gets executed and as a result, pops out of the main Execution stack.

After the specified time in setTimeout API, which in our case is 1000ms, the browser sends this task(our callback function) to the callback queue.

At this point Execution Context is empty, and our callback function is sitting in the Callback queue waiting for the opportunity of execution. Here a very important question arises, What next, and What connects the callback queue and the Callstack? You guessed it right, the event loop.

The Eventloop

The event loop is a special mechanism in JavaScript which keeps an eye on the Callstack and the Callback Queue. Its main purpose is to transport callback functions from the Callback queue to the Callstack for execution, once it is empty.

The Callback queue works in a FIFO(first in, first out) manner. Mean the oldest callback will be sent to the Callstack first. You can imagine the Callback queue simply as an array, which adds new callbacks with Array.push() method to the end of the queue and takes the first callback out using Array.shift() method.

The event loop takes callbacks from the callback queue one by one and keeps doing this until the Callback queue is also empty.

As soon the Callstack was empty, the event loop looked in the Callback queue for any pending callback function. But will not find one. Probably you know the reason. The rest of our program will a be executed in few milliseconds but the browser sends our callback function(task) to callback queue after a specified time.
So what next? Did our program fail here? Of course not. As clear from the name, the event loop is a loop and keeps checking again and again.

After 1000ms our callback(task) is sent to the callback queue by the browser. At this point in time, the Callstack is already empty, and immediately event loop transfers our task to the Callstack, where it gets executed similar to any other program.

Hopefully, most of the concepts will be clear in your mind by now. If you still have some confusion, let's take a couple of more examples.

This program is exactly the same as the previous one with only one change, Delay time is set to 0 for setTimeout. Can you guess what would be the output of this code?

Well if you guessed 1 2 3, this is not the correct answer. Let me explain how?

The first statement console.log(1) will be executed exactly as we have already discussed.

The twist comes in the second statement, setTimeout. We have set a 0ms delay time, and we expect it to run immediately. And then 3rd statement should be executed. But this is not the case here.

When setTimeout is encountered and added to Callstack, and being a web API, it adds a task to the browser and fades out of execution context. As we haven't added any delay, immediately the browser sends our task to the callback queue.

At the very moment, the JavaScript engine is executing the 3rd statement of our program console.log(3). As Callbacks are only transported to the main Callstack after it is empty. Our callback has to sit and wait inside the Callback queue until our main Callstack is empty.

As soon FEC of console.log(3) finishes execution, the Callstack is empty, The event loop comes into play, checks the Callback queue for any pending scheduled tasks, and guess what finds one. The eventloop transfers our callback to the Callstack and it gets executed.

So this way output is 1 3 2 not 1 2 3. Reason is the fact that the eventloop only transfers callbacks from the Callback queue to Callstack after it is empty.

Challenge for you

I hope your concepts regarding Callback queue, Web APIs, and eventloop are clear now. So I have a little to do for you. Consider this code and predict the output. Sounds good?

Take your time, make notes let me know your first assessment in the comment section.

Let's do it together as well.

Step1

console.log(1) is added to the main Calllstack and executed. Pops out of the execution stack.

Step2

setTimeout no 1 is added to the Callstack, it adds a task to the browser and pops out of the stack.

At this stage, the browser container has 1 task(setTimeout 1), with a timer of 1000ms.

Step3

setTimeout no 2 is added to the Callstack next, and adds a task to the browser and pops out of the stack.

At this stage, the browser container has 2 tasks, task1(setTimeout1) and task2(setTimeout2) with a timer of 1000ms and 0ms respectively.

Here is the twist. We know that task2 was added after task1, but task2 has no delay at all 0ms. So task2 will be sent to the callback queue before the task1.

Let's update our state, at this point we have only 1 task left in the browser container(task1), and we have one callback function(task2) in the callback queue. So far only 1 statement was executed console.log(1).

Step4

Then comes the 3rd setTimeout API. It is added to the Callstack, it adds a task to the browser. This task3 has a 500ms delay. This means it will be sent to the Callback queue after half a second.

So far, we have 1 callback function(task2) sitting in the Callback queue, and 2 tasks, task1, and task3 waiting in the browser container with a delay of 1000ms and 500ms respectively.

Step5

Statement 5 in the main script is executed immediately and popped out of the Callstack.

Now we have executed 2 statements, 2 tasks are waiting in the browser container, and 1 task sitting in the callback queue.

Step6

Here comes out 4th and final setTimeout. It has a delay set to 250ms. It is added to the Callstack and pops out after adding another task to the browser. At this point in time, we have 3 tasks in the browser container;

Task1: Added by setTimeout1 with a timer of 1000ms.
Task3: Added by setTimeout1 with a timer of 500ms.
Task4: Added by setTimeout1 with a timer of 250ms.

As we know the task is sent to the callback queue after the time specified. So task 4 will go first, followed by task3, and task 1 will be added to the callback queue at the last.

State of Callback queue

As our Callstack is empty at this point, the Eventloop will start transferring callbacks to Callstack 1 by 1. This will happen first in, first out manner. Mean the oldest callback function will be sent to Callstack first.

So, first of all, task 2 will be transferred to the Callstack. It will be executed by logging 3 to the console.

Then, task 4 is transferred resulting in the logging of 6 to the console.

Then task 3 and at last task 1 logging 4 and 2 to the console respectively.

So do we get, 1 5 3 6 4 2. This is the magic key. Hopefully, you got the same.

Credits and Motivations

Elegant guide on JavaScript Runtime Environment by Gemma Croad.

Wrapping Up
So this was part 2 of JavaScript under the hood. Hopefully, you got some value from this guide, and if you did please let me know in the comment section. This will give me another level of motivation, so I keep writing articles like this.

Till then, Stay safe, and try to keep others safe.

See you soon💓

0 to 1- How JavaScript works under the hood

Azhar Dev — Mon, 18 Jul 2022 14:18:00 +0000

Many developers have been coding in JavaScript to carry out its legacy since Brendan Eich developed JavaScript back in 1995. If someone actually wants to learn JavaScript you need to understand JavaScript. You need to know the history of JavaScript, what problem it actually solves, and how JavaScript works behind the scene. This background info will help you out when you will be coding and when you are learning some new features.

In this article we will learn little history of JavaScript, how JavaScript works behind the scenes? What is the Runtime environment? What role does the JavaScript engine play in code execution? What the heck is Execution context? What is Scope, TDZ, and a lot more?

You ready 😉

JavaScript History

First of let's discuss the need for JavaScript, so you can have some idea of why are you using JS and what was its purpose.

In the early days of the web (yeah, stone Age 😉), there were ways to create web pages(HTML was released in 1993), but there was no effective way to manipulate them. As we can these days with DOM (Document Object Model - will be discussed later). So those static pages were usually non-interactive. This was the major reason some language needed to be developed to give them life.

Back in 1995, Brendan Eich stepped forward and developed the first version of JavaScript in mere 10 Days, it's not a typo I really meant 10 Days. It was then called LiveScript(cool name, but I like JavaScript more 😉). At that time JavaScript was like alien technology and was adopted quickly. The community kept expanding, it got better and better, and of course, JavaScript we use is a monster compared to those days.

At first, It was developed for Netscape 2 and became the ECMA-262 standard in 1997. In 1997, ECMAScript 1 was released and was supported in Internet Explorer 4 for the first time. Then in 1998, ECMAScript 2 came out, and ECMAScript 3 in 1999. This fourth edition of the language was a bit delayed and was released in 2008 but could not make it to market. The fifth major edition, ECMAScript 5 was released in 2009. This version was used for a while and the latest version ECMAScript 6 was released back in 2015, which is now widely supported in all major browsers with and exception the of Internet Explorer. Here you can learn more about the history of your favorite language.

Here ECMAscript is

ECMAScript is a JavaScript standard meant to ensure the interoperability of web pages across different web browsers. It is standardized by Ecma International according to the document ECMA-262. Bascially it standardizes what JavaScript code dos what, so JavaScript behaves the same way in every Browser.

You cannot possibly learn the language if you do not know how that Language works under the hood. Let's first understand a few important concepts we will be using a lot in this article.

JavaScript in plain English

JavaScript is an interpreted language, which means, like Java(no similarity with JavaScript except name ), it does not require us to compile it before sending it to Browser to be executed, the interpreter can take raw JS source code and execute it for us.
JavaScript is single-threaded and synchronous in nature. This means it creates and executes all the tasks with a single execution thread. Tasks are queued one after another and the next task needs to sit and wait until the active task is completed. There are still ways to run JS code asynchronously, which we will discuss further in this article.
JavaScript is non-blocking programming or scripting language which does not block upcoming tasks if a program is taking so long, with the help of Web APIs, Callback queue, and event loop. For now, you might find this non-blocking statement contradictory to the above single-threaded statement. But we will discuss all these concepts in great detail in a while. You just need to be with me for the next few minutes.
JavaScript is a dynamically-typed language, which means var can store any data type, like int, string, or object, unlike other statically typed languages like C, and C++ in which we have to explicitly specify variable type datatype variable_name.

The Runtime Environment

The Runtime Environment is a special environment that provides our code access to built-in libraries, APIs, and objects to our program so it can interact with the outside world and get executed to full fill its noble purpose.

Runtime Environment is basically a factory where raw JavaScript code gets loaded and with a mixture of Web APIs, libraries, and objects it gets executed. Hopefully, this gives you some sense of the runtime environment. If you still have some doubts, do not worry we will be discussing components of the runtime environment and their part in JS execution in a short while. You just need to hang tight with me, and you will have a very clear picture of JS at the end of this guide.

In the context of a web browser, the runtime environment consists of following components:

JavaScript Engine
- The Callstack or Execution Stack
- The Heap
Web Apis (like fetch, setTimeout, DOM, File API)
The Callback queue
The Event Loop

Runtime environment depends on the context, in which you are running JavaScript code. The runtime environment might look a bit different depending upon the context. For instance in NodeJs environment JavaScript code has no access to Web APIs because they are a feature of web browsers. Basic features will be the same or similar though in case of any context.

A modern browser is a very complicated piece of software with tens of millions of line lines of code. So it is split into many modules which handle different logic.

Two of the most important parts of a web browser are the JavaScript engine and a rendering engine.

Rendering Engine

The rendering engine paints content on the screen. Blink is a rendering engine that is responsible for the entire rendering pipeline including DOM trees, styles, events, and V8 integration. It parses the DOM trees, resolves styles, and determines the visual geometry of elements on the screen.

JavaScript Engine

The purpose of the JavaScript engine is to translate source code that developers write into machine code (binary) that processor can understand. So this is the place or factory you can say, where raw JavaScript gets downloaded, parsed, and transpiled into Machine code that can be understood by Processor.

JavaScript engine compiles and executes raw JavaScript source code into native machine code. So JavaScript engine is the place where JS source code is downloaded, parsed, interpreted, and executed at the end in form of Binary code. Every major Brower vendor has developed its own JavaScript engine, which basically works the same way. Like Chrome has V8, Safari has JavaScriptCore, and Firefox uses SpiderMonkey.

We will be focusing on the V8 engine in this article. Read what is V8 Engine from Google's words;

V8 is Google's open-source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome and in Node.js, among others. It implements ECMAScript and WebAssembly, and runs on Windows 7 or later, macOS 10.12+, and Linux systems that use x64, IA-32, ARM, or MIPS processors. V8 can run standalone or can be embedded into any C++ application.

Working of JavaScript Engine(V8)

The first version of V8 was released and used by the Google Chrome team in 2010 when they had some problems displaying Google Maps. Later on, they improved it over time and released another version of V8 in 2017, which is being used by Chrome browser these days.

The current version was built on this model;

[Image copied from this awesome article by Uday Hiwarale]

Let's break it down;

V8 engine downloads JS source code and passes it to Baseline Compiler which process and compiles code to lightweight ByteCode.

This bytecode gets passed to an interpreter which is basically an IntelliSense algorithm that knows what JS code dos what. It interprets the bytecode to CPU understandable binary code.

At the very same time, Bytecode gets passed to the Optimization compiler which optimizes this ByteCode in the background while the application is running. It produces a very optimized binary code, which is eventually replaced with the code in the application, thus giving massive performance and boost.

This is the final model of the V8 engine. But this was not always like this. After many updates and remodeling, this very optimized version of the engine came into existence.

This is the basic functioning model of Chrome JavaScript Engine(V8). Other browser vendors use different JavaScript engines. But they function pretty much a similar way.

How JavaScript code works in the runtime environment

Unlike other programming languages, JavaScript is single-threaded in runtime, in plain English means it can run only one piece of code at a time. Code runs sequentially, so when one process is taking longer to run, it blocks the rest of the code after that waiting to be executed. Hence sometimes you might see, a Page Unresponsive alert. That usually occurs when some infinite loop of code is encountered in runtime. And it keeps running until all the CPU resources are consumed.

Consider this eternal loop;

Here is what happens when this program is opened in Browser, it uses a single JavaScript execution thread, which is responsible for handling everything on the web page, like scrolling, events handling and fetching data from the server.

When this kind of infinite loop or huge JavaScript program is encountered, the execution of code gets blocked after it. Because JavaScript is single-threaded in nature and runs one piece at a time. Thus infinite loops keep running again and again until the system is out of resources. And we have to see the "Page Unresponsive" dialog.

Thanks to modern browsers they use separate JavaScript execution threads for different tabs, otherwise, our browser would have been frozen if such a heavy program or infinite loop was encountered in one tab on one page. Modern web browsers usually use separate execution threads for different tabs or a single execution thread for one domain (same website on multiple tabs). Chrome uses a one-process-per-site policy so, if multiple domains were open in different tabs, all of them will stop working. Other domains (websites) tabs will keep working fine.

Let's discuss the JavaScript engine in detail. JavaScript engine consists of mainly two components; The Callstack and the Heap.

The Heap

The heap is the unstructured memory storage where variables and objects get stored during program execution. Then the heap, also known as the "memory heap" gets cleaned during garbage collection. I will not talk about it in detail, you can check out this awesome article.

The Callstack or Execution Stack

We are interested in the call stack, which is basically a LIFO (first in, last out) data storage where current executing contexts are stored while the program is running. We will discuss what Execution Context is in detail in a while. Each entry in the call stack is called a Stack frame. A stack frame contains information about the Execution Context, like its argument object, return address, local variables, etc.

What is an Execution context?

JavaScript engine creates a special environment for the execution of JavaScript code, which contains the code that is currently running and everything that aids in its execution. This special environment is called the Execution context.

During the Execution context runtime, specific code gets parsed by a parser, variables and declarations get stored in memory(VO), and executable bytecode gets generated which is then converted to binary code, which gets executed.

Two kinds of execution contexts are created during runtime;

Global Execution Context(GEC)
Functional Execution Context(FEC)

Global Execution Context(GEC)

When the JS engine receives some script file, a default Global execution context is created to handle the code at the root of that file, everything which is outside of any function.

This is the main/default execution context, that encapsulates all of the functional execution contexts.

There is only one GEC for any script file.

Functional Execution Context(FEC)

When the Global execution context encounters a function invocation, a different kind of execution context, very specific to that function gets created which handles all the logic inside that function.

As there are usually multiple functions inside any script (JavaScript file), every function gets executed in its very own execution context, and there can be multiple Functional Execution Contexts in a single program.

How Execution Context is created?

As we already know that execution context has two major tasks, it prepares the script and then executes it. So we will try to understand the execution context in two phases;

Creation Phase
Execution Phase

Creation Phase

The creation phase of any execution context completes in three main steps.

Creation of Variable Object
Creation of the scope chain
Assignment of this value

Creation Phase: Creation of Variable Object(VO)

For GEC a variable object is created which is basically a memory container, which stores properties for all variables and function declarations and stores references to them. When a variable is encountered in a global execution context property is added to the Variable Object and is initialized(in case defined with var) with the default value undefined.

When a function declaration is encountered, a property is added to the Variable Object, and a reference to that function is stored as a value.

This means before even the start of execution of code, variables and function declarations are available to use. Due to hoisting. We will discuss hoisting in great detail in a while.

In case of, FEC (functional execution context) doesn't create a VO but an array-like object called the argument object. All the arguments received by a function are stored in this array-like object.

Hoisting in JavaScript

JavaScript moves all the variables, function declarations, and class declarations to the top of their scope. This process is called hoisting in JavaScript.

In plain English, Prior to the execution of code, JavaScript stores all the variables, functions, and class declarations in the memory container, called Variable Object at the top of the scope, this process is known as Hoisting in JavaScript. Basically hoisting is the reason we can access functions and variables even before they are declared.

Function hoisting

Some JavaScript developers choose to define all of their functions at the top of the script and later call them at the end. The code below will still work fine due to hoisting, although we are calling the function before it was declared.

Variable Hoisting

Variables declarations are also hoisted. Variables declared with the var keyword are hoisted and initialized with a default value undefined. Mean if you will try to access a variable declared with var, you will not get an error but the value will be undefined.

If you declare a variable with a let or const keyword, their declaration is hoisted but not initialized with a default undefined value. That's why you will get an uncaught ReferenceError, when we try to access it before the declaration.

Here one thing is really important to discuss. You might be asked in an interview about this.

Starting from the top of the scope, until the complete initialization of a variable, that variable is said to be in Temporal Dead Zone(TDZ). You should always try to access variables outside of its TDZ. If you try to access the variable from inside its TDZ, you will get ReferenceError. Here the question arises of where TDZ starts, and where it ends.

See the code below, you will know Temporal Dead Zone starts at the start of the code block(top of scope) and ends at initialization. Variables declared with let and const follow the same pattern.

In the case of variables declared with var the scenario is a bit different. And a guilty guy is hoisting. As we already know variables declared var are hoisted and initialized at the same time with a default value undefined. And we also know TDZ ends when a variable has been assigned a value.

This is the reason var behaves a little differently compared to let and const. See this code;

Hopefully, TDZ is all clear to you. Let's get back to hoisting.
There is one strict rule of hoisting, that hoisting only works for statements, not expressions. Have a look at this code;

This is because we are assigning a function expression to a variable as a value. As we all know variables declared with let keyword are hoisted, but throw ReferenceError if called within Temporal Dead Zone. This is because their value is not initialized during hoisting and TDZ only ends after the complete initialization of the variable.

Quiz Time: Here is a small question for you? What would be the output if we used var instead of letting in the above code example. Can you guess whether any error will be thrown or function output will be logged to the console?

I am sure you guessed it right. The error will be thrown in this case stating something like myFunc is not a function, because at this stage value of the myFunc variable will be undefined due to Hoisting. So calling undefined() will throw an error.

Creation Phase: Creation of Scope chain

The scope is a mechanism in JavaScript which determines which piece of code is accessible from where. When a variable, function, or class is declared in a script, it has some address and some boundaries. Beyond those boundaries, it is inaccessible. The scope does answer many questions like from where code can be accessed? and from where it can not be?

First of all, when the script is loaded in the engine, global scope is created, which basically holds everything which is not inside any function. All the functions and their inner functions can access this global scope.

When a function is defined in another function, the inner function has access to the code defined in that of the outer function, and that of its parents. This behavior is called lexical scoping.

Whenever a variable or function is called somewhere, the engine starts looking for an inside the local scope, where it was called. If not found, it looks for parent scopes (Lexical Scoping) one by one, from inner(local) to outermost (global scope). If the variable was not found in local and all the parent scopes including the global root scope, then the engine throws an error.

Every function execution context creates its scope which determines what variables and functions are accessible where. There are a few cases that we need to discuss to completely understand scoping.

Case 1: Variables declared inside a function can be accessed from anywhere inside that function, except for Temporal Dead Zone.

Case 2: Function declared inside a function has access to everything of its parent function and parent's parent function up to the global scope. This is called Lexical Scoping. This concept gave rise to something called closures in JavaScript.

When a function inside another function is called outside of its context, means outside of the parent function in which it was declared but it still has access to variables of the parent function even after the parent function has finished execution, this associative phenomenon is called closures. This is a very important concept and you definitely should check it out here.

Parent function has no access to anything declared inside of its child functions. The scope is like a one-way mirror, which means you can look outside but now one can look inside.

[Image copied from this awesome article by Victor Ikechukwu at freeCodeCamp]

As you can see in this image, the function second has access to all scopes including its own local scope, the scope of function first, and the global scope. But function first has only access to its local scope and the global scope. You can see it has no access to the scope of function second.

The second step of the creation of the Execution context completes here.

Till now Variable object has been created, scope chain is in place. Let's discuss the third and final step.

Creation phase: Setting the value of `this`

The next and final step in the creation of execution context is setting the value of this. this is a special keyword in JavaScript which refers to the scope of the environment where the Execution context belongs.

Value of this is different, depending on the context it is being used. Have a look at these cases;

Case 1: In Global Execution Context, this refers to the global window object in the case of browsers. Try logging "this" to the console inside GEC and you will see a window object. Here is one interesting thing to notice. When you define a variable or function inside GEC, they are saved as a property of the window object. This means these 2 statements are equivalent;

And this will log true to the console;

Case 2: Inside FEC, a new this object is not created, but instead, it refers to the context it belongs to. Like, in this case, this refers to the global window object. As this function is declared in GEC, this would refer to the global window object.

Case 3: In the case of objects, using this inside the methods does not refer to the global object, but the object itself. Look at this example;

Case 4: Inside constructor functions, this refers to the newly created object, when called with new keyword like this;

With this, the creation phase of Execution Context has been completed. Till now, everything has been stored in VO, the scope chain is created and the value of this is in place.

Execution phase

Right after the creation of the execution context. JavaScript engine starts the execution of created context. But Variable Object currently contains all the declarations of that specific execution context but their value is undefined. And you already know we cannot work with undefined. So JavaScript engine again looks through VO once again and feeds their original values. After this code gets parsed by the parser engine, gets transpiled into lightweight bytecode, which is then converted to binary code(01), which then gets executed.

JavaScript Callstack(in terms of execution context)

First of all, the script is loaded in the browser, JavaScript engine creates the Global Execution Context. This GEC is responsible for handling all the code that is not inside of any function.

Initially, this GEC is the active execution context. When some function is encountered in this GEC, and new Functional Execution Context is created for the execution of that function. That FEC holds all the information about the execution of that function and everything that aids in its execution. This newly created execution context is placed right above the GEC. This process is repeated for every function call and FEC is added and piled up in the so-called Callstack.

Execution context on the top is executed first, and once that context is executed (something returned), it is popped out of the stack. The very next context becomes an active one and its execution starts. This process is repeated until there is the last GEC left in the stack. It is executed at the end and the script is said to be executed at this point.

Conclusion

et's sum up all of this by an example. We try to recall everything we have learned so far in this article.

Consider this program inside the script file;

First of all this .js file gets loaded in the browser, and passed to the JavaScript engine for execution. The engine creates a Global Execution Context for this file which handles the execution of the root of this script file, everything that is not inside a function. This GEC is placed at the bottom(or top) of the Execution Stack. Global Execution Context is created during two phases; the creation phase, and the execution phase.

Variable name="Victor" is stored in the Variable Object (VO) of GEC and initialized with the default value undefined (hoisting).

Then for all these functions first, second and third, a property is added to VO of GEC, and reference to these functions is stored as value. Hoisting you know 😉.

After setting the VO of GEC, the scope chain is created, and value is this set (window).

Now starts execution. But the value of name variable is still undefined in the VO. And we cannot work with undefined, Right? So once again JS engine looks through VO and feeds the original value of name variable, which is Victor. Now we are good to proceed further in our program.

First of all, the function first gets invoked. JS engine creates a Functional Execution Context to handle its execution. This FEC is placed on top of the Global Execution Context, forming a Callstack or Execution Stack. For the period of time, this FEC is the active one, as we already know Execution Context on the top in Callstack is active. Variable a = "Hi!" gets stored in the FEC, not GEC.

In the next statement, function first invokes function second. Another FEC is created and placed on top of the FEC of function first. Now this FEC is active. Variable b="Hey!" gets stored in the FEC.

Then function second invokes function third, similarly, FEC is created, and placed on the top of the Execution stack. Variable c = "Hello!" gets stored in the FEC.

So far Execution Stack looks like this;

And logs Hello Victor to the console. But wait! Where does Victor come from? Variable name is not defined in the function third. You guessed it right, Scope Chain. The function third looks for name variable inside its local scope, but did not find it. Because of something called Lexical Scoping, it also has access to its parent scope, the Global scope. JavaScript engine looks for name in global scope and finds it.

When function third has completed all of its purposes, its FEC gets popped out of the Execution stack(Callstack).

Then the very first FEC below it becomes active context and starts execution. Logs Hey! Victor to the console' and pops out of the Execution stack. Now the last FEC of this program becomes active, logs Hi! Victor to the console. After execution of all of the statements, it is destroyed and pops out of the Callstack.

We are again left with only GEC in the Execution stack. As well it has nothing left to execute it also pops out of the stack.

Hopefully, this example cleared up most of your doubts. We have discussed the first component of the JavaScript Runtime Environment so far. Hopefully, you find it helpful.

So far we have learned

A little history of JavaScript
JavaScript Runtime, which is basically a special environment provided by the browser or context we run our code in. This environment provides us with objects, APIs, and other components so our code can interact with the outside world and get executed.
Components of runtime environment; like JavaScript engine, Web APIs, Callback queue, and Eventloop.
JavaScript engine, which again consists of Callstack or Execution Stack and the Heap.
Execution Context, which is basically a special environment for the execution of JavaScript code, contains the code that is currently running and everything that aids in its execution. This special environment is called the Execution context.
Types of execution context; like Global Execution Context(GEC) and Functional Execution Context(FEC).
The creation phase of Execution Context, which completes in three phases; Creation of VO, Scope chain building, and the setting value of this.
The execution phase of Execution Context, we learned how GEC is created once the script is loaded and how every function creates its own FEC. They keep stacking on one another unless they return something and get popped out of Stack.
Scoping and Temporal Dead Zone, we learned how functions can access declarations from their parent scope via Lexical Scoping. We briefly discussed TDZ as well.

The drawback of JS single-threaded nature

This is where Web APIs, Callback queue, and Eventloop come to the rescue. My plan was to discuss all of these concepts in a single guide, but the length grew more than I expected.

What Next?

Now we are left with the other three components of JavaScript Runtime,

Web APIs
The Callback Queue
The Eventloop

I will be dropping another guide like this on these left components. If you want to get notified of the next part, follow me 😉.

This was the first component of the JavaScript runtime, the Working of the JavaScript engine in the code execution. I have tried to simplify all the concepts so even absolute beginners can understand them. Hopefully, you were able to understand it, and found it helpful.

Credits and Motivations

While writing this guide, I found really awesome articles you should also check. These articles helped me write this extensive guide.

Really awesome article How does JavaScript and JavaScript engine work in the browser and node? by Uday Hiwarale.
An extensive article on JavaScript Execution Context by Victor Ikechukwu.
Elegant guide on JavaScript Runtime Environment by Gemma Croad.

Final Words

If you liked this guide and want to get notified of my next articles like this, please do follow me. If your friend is struggling with these concepts, do share this guide.

Till then, Stay safe, and try to keep others safe.

See you soon💓

Implementing Layout Structure in NextJs the right way

Azhar Dev — Mon, 04 Jul 2022 10:16:38 +0000

Intro & Why Layouts?

When I started coding in NextJs, I really struggled while implementing Layout based architecture. The React model allows us to deconstruct a page into a series of components. Many of these components are often reused between pages. For example, you might have the same Header and Footer on every page.

I read some articles and came to a proper solution for Layout based architecture in simple or complex NextJs applications.

Tutorial Outcomes

At the end of the tutorial you will be able to;

Create a global layout for NextJs pages
Create multiple dedicated layouts for different type of pages like GlobalLayout, DashboardLayout.
You will learn how to fix remount and state persistence issues while implementing layouts in NextJs.

Setting up the NextJs project

Let's create a new NextJs project by running CNA(create-next-app) command with the default template, in the terminal(personally prefer Git Bash),



npx create-next-app <app-name>
# or
yarn create next-app

Navigate to project directory,



cd <app-name>

Run newly created NextJs app in a development environment,



npm run dev
// or
npm start

Now application should be running at localhost:300.

Lets look at the directories you will get after bootstraping NextJs application;



/<app-name>

   /pages

        /_app.js

        /index.js

   /public

   /styles

Adding necessory components

Create another file inside the pages directory, named about.js, which will be mapped to /about as About page.

Create another directory inside the root directory as components;

Inside the Components directory create directories named, Layout, Header, and Footer, each with index.js file inside it.

The project directory should look like this;



/<app-name>

   /pages

      /_app.js

      /index.js

      /about.js

   /public

   /styles

   /components

      /Layout

          /index.js

      /Header

          /index.js

      /Footer

          /index.js

Adding Content

Now open index.js inside the /pages directory, and clean up the mockup code initially created by running the create-next-app command. Add the following code instead;

And inside the about.js page,

Implementing Layout

Now you can see, that Components like the Header, Footer are being shared between both the pages. We are going to separate these shared components inside the Layout component, so we do not need to import them in every single page.

Open the index.js file inside Layout directory and add this code;

What are we doing here exactly? Nothing special. We are using the childrenprop provided by reacting, which will let us wrap pages inside Layout. Anything wrapped inside this Layout component will be added to react render tree between <main> tag at,

<main>{children}</main>

Now let's implement this layout inside our pages, and make the following changes to index.js and about.js inside pages directory;

and inside /pages/about.js,

Hurrah! We got it. We have successfully implemented Layout architecture inside our NextJs app. But hold on, there is a major drawback to this implementation. Unnecessary remounting and rerender at every navigation 😒. Let me explain.

Fixing the Remounting and Rerendering issue

First of all, let me demonstrate what I mean by unnecessary re-renders and remounting issues. Let's start a development server, by running

npm run dev or npm start

If you had followed me along, you must see this basic page when visiting localhost:3000 in browser of your choice(unless its Internet Explorer 😉)

Isn't it ugly, right? 😊, I guessed your answer. Let's give it a bit of shape with Tailwind CSS(really awesome, if you haven't tried it, you should give it a shot).

I have added some styles, and a useEffect hook to demonstrate to you, what is actually going on. Have a look;

The useEffecthook was provided in ReactJs after v16.8, which pretty much replaces the 3 life cycle methods (componentDidMount, componentWillUpdate, componentWillUnmout) of react class-based implementation.
Now our Header component should look like this;

Testing Phase 1

Setup is done, now let's test this out. Open a terminal, and refresh your page. You must see in the terminal Header mounted;

Now it's time to navigate to the About page, by clicking About in the Header, you will see that header first unmounts and then re-mounts again.

Is this okay? You guessed it right. When navigating between pages, we want to persist page state (input values, scroll position, etc.) for a Single-Page Application (SPA) experience. But in our case, this is doing nothing, just separating the shared components, which is good but now what we want to achieve.

Okay! Fix time

NextJs comes with the solution itself, by providing us with getLayout method. We need to refactor this code a bit, and we are good to go.

When using Next.js we often need to override the global App component to get access to some features like persisting state, or global layouts. This can be done by creating a file_app.js directly in the /pages/ folder. If this file exists, then Next.js will use this instead of the default App.

Time to mess with _app.js file;

What are we exactly doing here, we are telling NextJs to use Layout as specified at the page level, while preserving the memory(state, scroll position, etc.). When navigating between pages, we want to persist page state (input values, scroll position, etc.) for a Single-Page Application (SPA) experience.

This layout pattern enables state persistence because the React component tree is maintained between page transitions. With the component tree, React can understand which elements have changed to preserve the state.

Refactoring Page Layouts

Let's refactor code inside pages, index.js and about.js.
Move the Layout from the component return state to Component.getLayout method like;

and for /about.js page;

Testing

Let's test it again. clear console and refresh again. You must see a message Header mounted in the console, now try to navigate to the About page, and Boom 😍.

You see that no more remounting, state loss. We together have just implemented a proper Layout architecture in NextJs.

Conclusion

You can easily add multiple layouts inside your NextJs app, like Dashboard Layout, etc. You just need to create a Layout, and add common components, like a Sidebar, Dashboard Header, and Dashboard Footer in case of Dashboard Layout. And the next step would be to wrap pages inside this layout.

Simple isn't it.

Hopefully, you got some value from this article, in case you have any queries please let me know in the comment section.

Thanks a lot. I am Azhar Zaman and I will see you in another amazing tutorial like this.

Till then be safe and try to keep others safe.