DEV Community: Rishu Patel

Async vs Defer in javascript

Rishu Patel — Sat, 12 Feb 2022 16:14:00 +0000

Introduction

How many times have you added javascript to your HTML like this <script src="path/to/some/javascript"></script> but have you ever pondered how browser handle that line of code? Why do we sometimes pass async or defer attributes to the script tag?

In this article, we'll take a look and understand major differences between async and defer attributes and which one is better to use. But first, let's understand what if we don't use them at all.

`<script>` tag without async or defer

Let's take a look at the following code.

<html lang="en">
  <head>
    <title>Async vs Defer</title>
    <script src="path/to/some/javascript"></script>
  </head>
  <body>
    <h1>Async vs Defer</h1>
  </body>
</html>

When the browser runs this file it starts by parsing the HTML line by line. In this example, as soon as the browser sees the script tag, it stops the HTML parsing and starts to fetch the javascript file and it also executes the javascript line by line immediately after it fetches the javascript file.

During this fetching of the javascript file, the HTML parsing is stopped and this delays the content rendering on DOM and eventually slows down the website.
This is not a good thing because if you are working on a large project then even a delay of say 1 second might lead people to go back from your website and eventually hurt the revenue.

We can solve this by using async or defer so let's take a look at them.

Async Attribute

<script async src="path/to/some/javascript"></script>

When we use the async attribute in a script tag. The browser starts by parsing the HTML file and when the browser sees the script tag it starts fetching the javascript in the background while continuing the HTML parsing. Once the script is available to be executed then the browser stops the HTML parsing and executes the Javascript file line by line. Once the javascript execution finishes the browser continues the HTML parsing.

Defer Attribute

<script defer src="path/to/some/javascript"></script>

The defer attribute is quite similar to async. The one difference is that the scripts loaded with defer attribute are not executed until HTML parsing is completely finished. What that means is browsers start by parsing HTML and fetches the javascript in the background if it encounters any script tags and continues the HTML parsing. Javascript is executed only after the HTML is completely parsed.

Problem with `async`

If multiple scripts are being used in HTML file and some are dependent on others, so in order for them to work correctly, we need to make sure that the script on which others are dependent are loaded and executed first in the browsers before the script which is dependent on this script.

The async attribute does not guarantee the order in which different javascript files are executed.

Let's take an example,

<script async src="script-1"></script>
<script async src="script-depended-on-script-1"></script>
<script async src="script-depended-on-script-above-this"></script>

If we use async in this case then it does not guarantee that script-1 will be loaded and executed before the script-depended-on-script-1 because these scripts are being fetched in the background and one might be fetched before the others due to any reason, like its size or network issue. So if script-depended-on-script-1 is fetched first then it will be executed first because when using async attribute browsers execute the javascript immediately after it is available or downloaded in the browsers.

defer however guarantees that scripts will be executed in the order even if one is available to the browser before the other because all scripts will be executed after the HTML parsing is done.

Conclusion

If you have multiple scripts that are dependent on each other then use defer as it guarantees the order of execution.
If you don't want to block the HTML parsing then use defer
I personally recommend using defer most of the time.

I hope you found this interesting and learned something. Thank you.

Per Aspera Ad Astra

How to create a react component library using Storybook, TypeScript, SCSS, and Rollup?

Rishu Patel — Fri, 11 Feb 2022 21:44:00 +0000

Introduction

The beautiful thing about react is that it lets you break down UI into smaller components and reuse them at multiple places in your project, but that's not it, you can standardize your components and publish them to npm or yarn and let other people use your components in their projects.

In this post, I'll show you how you can create a component library for reactJS using Typescript, Storybook, SCSS, and Rollup.

It's not necessary to create a big library, you can create a library for a single component such as a Date Picker or you can create a full-fledged library like material UI.

A UI component library is very essential for organizations to maintain a consistent UI across different projects. However, you do not need to create a component library just for a single project as all components can be maintained in that particular project but if you work on multiple side projects and have similar components that you copy-paste from one project to another then it is better to create a library for those components.

So let's get started with our library

Setting up the library

Getting Started

Before starting this project make sure you have node js and npm installed globally in your system. If not, you can download node from here

Create a folder and name it whatever you want, but for the sake of this article let's name this folder react-lib, and if you are planning to publish this library to npm then check if the package name is available on npm registry

Open Terminal and navigate to your project directory and run

npm init -y

This initializes a node project in the current directory. The -y flag when passed to the NPM command tells the generator to use the defaults instead of asking questions, and a file package.json is created at the root of your directory

React & React DOM

Let's install react and react-dom as dev dependencies

 npm i -D react react-dom

We are creating this library for reactJS so it is required that a project that uses this library must have react and react-dom as dependencies so let's add react and react-dom as peer dependencies in our package.json file.

Basic Folder Structure

Before adding storybook and typescript and moving further let's create a basic folder structure for our project. You can have any folder structure that you prefer.

Installing Typescript

First, install typescript globally in your system with the following command

npm i typescript -g

Then install typescript and @types/react as a dev dependency in your project.

npm i -D typescript @types/react

Then create a tsconfig.json file using the following command.

tsc --init

This file will allow you to configure further and customize how Typescript and tsc compiler interact.

Open tsconfig.json and change the following configuration.

...
"compilerOptions" : {
    ...
    "jsx": "react",
    ...
    "module": "es6",
    ...
    "moduleResolution": "node",
    ....
    "outDir": "./dist",
    ....
  }
....

Getting Storybook

Storybook is an open-source tool for building UI components and pages in isolation. It streamlines UI development, testing, and documentation. It works with a javascript library such as React, Vue, Angular, etc.

To install the storybook in our library run this command:

npx sb init

You should now be able to run Storybook locally by running npm run storybook or if you prefer yarn storybook.

Here is a preview of the Storybook application:

Making sense of the folder structure

npx sb init generates some files and folders let's take a look at them

The `stories` folder

Storybook is smart enough and detects that the project uses Typescript and React so it creates some example components and documentation pages inside the stories folder in src. You can go ahead and remove everything from this folder but I recommend taking a peek inside to explore a little.

Introduction.stories.mdx contains the documentation used to generate the Introduction page in the storybook preview above. Files with .mdx extension are written using MDX which is an amalgamation of JSX and Markdown. It helps to write component stories alongside their documentation at the same place.
All files like <ComponentName>.tsx are the react components created with typescript and files like <ComponentName>.stories.tsx is used to preview the stories in the storybook and helps us to develop component in isolation

The `.storybook` folder

Contains files for customizing Storybook:

main.js defines the file pattern used by Storybook to determine what to include in the showcase application. By default, Storybook uses files containing .stories in their name.

"stories": [
   "../src/**/*.stories.mdx",
   "../src/**/*.stories.@(js|jsx|ts|tsx)"
 ]

Addons for the Storybook application are also defined in main.js.

"addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials"
  ]

preview.js configures how actions and controls will show up depending on the prop's name. By default, props such as onClick, onSubmit that start with on are automatically interpreted by Storybook as actions, so when triggered, they get logged inside Storybook's Actions addon. Besides, props suffixed with background and color will show a color picker control, whereas props suffixed with Date display a date picker control.

export const parameters = {
  actions: { argTypesRegex: "^on[A-Z].*" },
  controls: {
    matchers: {
      color: /(background|color)$/i,
      date: /Date$/,
    },
  },
}

The `package.json` file

npx sb init command adds all dev dependencies needed by the storybook and it also adds the following scripts in the package.json file


  "scripts": {
    "storybook": "start-storybook -p 6006",
    "build-storybook": "build-storybook"
  }

npm run storybook starts a development server locally on your machine
npm build-storybook builds the static storybook application ready to be deployed

Adding SASS support

Storybook uses webpack to bundle all the code when we run storybook or build-storybook script.
By default, Storybook does not come with sass support. In order to add sass to our library, we need to add some packages and extend the webpack config in .stoybook/main.js

Add the following dev dependencies for adding sass support

npm i -D sass style-loader css-loader sass-loader@10.2.0

Let's understand these dependencies

sass is a pure JavaScript implementation of Sass.
style-loader inject CSS into the DOM.
css-loader interprets @import and url() like import/require() and will resolve them.
sass-loader loads a Sass/SCSS file and compiles it to CSS. We are using a specific version because the latest version of sass-loader has a conflicting peer dependency issue with webpack that is used by the storybook internally.

To extend the webpack configuration lets add the following code in .storybook/main.js

const path = require("path");

.....
addons: ["@storybook/addon-links", "@storybook/addon-essentials"],
framework: "@storybook/react",
webpackFinal: async (config, { configType }) => {
    // Make whatever fine-grained changes you need
    config.module.rules.push({
      test: /\.scss$/,
      use: ["style-loader", "css-loader", "sass-loader"],
      include: path.resolve(__dirname, "../"),
    });

    // Return the altered config
    return config;
  }
....

With Sass support added, we are ready to build our components.

Creating our first component

Creating a button component

You can create any sort of component that you need to, but for the sake of this post let's create a Button component that can be reused.

Inside the components folder, create a file named Button.tsx .

First, we'll define the interface of the props that are required by the button.
We start by importing react inside our file and our button props extends the HTML button element as we might pass different props like onClick or type that are native to the HTML button element.

import React from "react";

export interface ButtonProps extends React.HTMLAttributes<HTMLButtonElement> {
  children: React.ReactNode;
  variant: "primary" | "danger"; 
  shape?: "rounded";
}

We are getting the following props

children that will be rendered inside the button element.
variant : the variant of button i.e. primary or danger in this case.
we also have an optional shape prop.

Now Let's add our component

export const Button: React.FC<ButtonProps> = ({
  children,
  variant,
  shape,
  ...props
}) => {
  const classNames = `btn btn-${variant} btn-${shape}`;
  return (
    <button className={classNames} {...props}>
      {children}
    </button>
  );
};

Here we are returning an HTML button element from our function and we'll use the variant and shape prop to create different classNames and add them to our <button> element and we can target those particular classes from our SCSS to give different styles to our component.
For example, btn is the base class and when we pass a variant then we'll have a class either btn-primary or btn-danger depending on the variant passed, and we can add styling to different variants.

Adding styles for Button component

Create a global.scss file inside the scss folder. You can choose a folder structure of your choice and put SCSS code in different files and import them in this global.scss file, but for the sake of simplicity let's add all our styles in the global.scss file.

/* base styling for our button */
.btn {
  padding: 0.6rem 1rem;
  background: transparent;
  border: 1px solid #1e1e1e;
  cursor: pointer;
}

/* styling for our variants */
.btn-primary {
  border: none;
  background-color: blue;
  color: white;
  &:hover {
    background-color: blue;
  }
}
.btn-danger {
  border: none;
  background-color: red;
  color: white;
  &:hover {
    background-color: red;
  }
}

/* styling for different shape*/
.btn-rounded {
  border-radius: 0.4rem;
}

Either the button will have a btn-primary class or a btn-danger along with other classes and the respective styles will take effect.

Now we have created our button and added some styles let's use this button and see how it looks in our storybook.

Creating the Button story in storybook

Before creating a story for our button let's import our SCSS so that it can be used. Open the preview.js file inside the .storybook folder and import the global.scss file inside it.

With our styles imported into the storybook let's create the Button Story.
Open the stories folder and delete all the files that were generated automatically by the storybook for us inside this folder and create a Button.stories.tsx file and write the following code

import React from "react";
import { Story } from "@storybook/react";
import { Button, ButtonProps } from "../components/Button";


export default {
  title: "Button",
  component: Button,
};

const Template: Story<ButtonProps> = args => <Button {...args} />;

export const Primary = Template.bind({});
Primary.args = {
  children: "Primary",
  variant: "primary",
};

export const Danger = Template.bind({});
Danger.args = {
  children: "Danger",
  variant: "danger",
  shape: "rounded",
};

Let's understand this code

We import our Button and ButtonProps from the Button.stories.tsx file and we start by exporting a default object that contains some metadata about this story like title and component. The title is the Actual Title of this story and inside the component, we have our Button component.

Then we create a Template function that takes some arguments and returns our button component.

const Template: Story<ButtonProps> = args => <Button {...args} />;

Now call Template.bind({}) for sort of creating a clone of our button template. This Template.bind({}) will return a function that we can store in a variable and export it. You can read more about .bind() here

export const Primary = Template.bind({});

Now set some args for our Primary button

Primary.args = {
  children: "Primary",
  variant: "primary",
};

Now run the npm run storybook command to start a development server and you'll see the button components

In the storybook's dev server, we have a control section that can be used to change props and see changes immediately or we can write more versions or variants of our button using Template.bind({}).

In this way, we can develop and test multiple components in isolation using the storybook.

Bundling using Rollup

Rollup is a good bundling tool, if we want to package the React component library and reuse it in other projects.

Rollup needs an entry point to generate the bundle. We have already created an index.ts file in the src folder which will serve as our entry point for Rollup.

Add the exports of the components in this index.ts file which will be used by others and also import the global.scss file here so we can create CSS bundle.

In order to build our library lets add the following dev dependencies.

npm i -D rollup @rollup/plugin-babel rollup-plugin-peer-deps-external rollup-plugin-scss rollup-plugin-terser @babel/preset-react @rollup/plugin-node-resolve @rollup/plugin-typescript

Let's understand these dependencies:

rollup gives the command-line interface (CLI) to bundle the library.
@rollup/plugin-babel allows us seamless integration between Rollup and existing Babel.
rollup-plugin-peer-deps-external prevents adding peer dependencies to the bundle because the consumer of the library is expected to have them. So we also get a smaller bundle size.
rollup-plugin-scss bundles scss files.
rollup-plugin-terser minify generated es bundle.
@babel/preset-react adds support for JSX.
@rollup/plugin-node-resolve helps resolve third-party modules in case you are using any third-party dependencies. If you use any third-party dependency it is going to resolve them and add them to the source code.
@rollup/plugin-typescript transpiles TypeScript files to JavaScript.

Next, we create a rollup.config.js file and add the following contents.

import { babel } from "@rollup/plugin-babel";
import external from "rollup-plugin-peer-deps-external";
import resolve from "@rollup/plugin-node-resolve";
import scss from "rollup-plugin-scss";
import typescript from "@rollup/plugin-typescript";
import { terser } from "rollup-plugin-terser";

export default [
  {
    input: "./src/index.ts",
    output: [
      {
        file: "dist/index.js",
        format: "cjs",
      },
      {
        file: "dist/index.es.js",
        format: "es",
        exports: "named",
      },
    ],
    plugins: [
      scss({
        output: true,
        failOnError: true,
        outputStyle: "compressed",
      }),
      babel({
        exclude: "node_modules/**",
        presets: ["@babel/preset-react"],
      }),
      external(),
      resolve(),
      typescript(),
      terser(),
    ],
  },
];

Next, we need to update package.json. Libraries should be distributed using CommonJS and ES6. We specify the output file paths using main and module properties. We also use these properties in the Rollup configuration file.

Then we add a build script that uses rollup CLI with -c flag. This means that Rollup will look for a configuration file named rollup.config.js to bundle the component library.

...
 "main": "dist/index.js",
 "module": "dist/index.es.js",
...
"scripts": {
    ...
    "build": "rollup -c", 
  }
...

Now if you run the npm run build command it will bundle our library and create a dist folder in the root of your project directory that could be deployed to npm.

Final Words

We have created a react component library from scratch using typescript. We installed the storybook for developing UI components in isolation and configured it to add SASS support and finally bundled everything together with Rollup.

I decided to write this article after I build a UI library for myself as a side project, if you are interested you can check it out here.

I hope you found this interesting and learned something. Thank you.

Per Aspera Ad Astra

How JavaScript Works?

Rishu Patel — Wed, 09 Feb 2022 22:01:00 +0000

Introduction

Have you ever wondered why JavaScript is considered such a weird language? Why does it behave unexpectedly sometimes? How is it possible to call a function even before declaring it? What is a closure or hoisting? Why setTimeout() function with a timer ⏳ of say 3 seconds may or may not exactly run after 3 seconds?
The answer to all these questions boils down to one thing i.e. How JavaScript works and how it is executed in the browsers? If you understand this one thing then many things in JavaScript start to make sense and you'll be able to catch bugs quickly and write better code.
In this article, I'll help you learn how JavaScript works?

Let's take a look at this statement

JavaScript is a synchronous single-threaded language

This means in Javascript statements are executed one at a time and in a specific order. Let's look at the following code.

console.log("foo") 
console.log("bar")

In the above example first foo then bar is logged inside the console.

In order to understand how JS works, we need to familiarize ourselves a little bit with The Call Stack

The Call stack

According to the MDN docs

A call stack is a mechanism for an interpreter (like the JavaScript interpreter in a web browser) to keep track of its place in a script that calls multiple functions — what function is currently being run and what functions are called from within that function, etc

Do you get it? NO. Let's take an example.

Imagine you have lots of books and you want to read them all so you come up with a solution. You stack all the books on top of one another and give yourself the following constraints.

To read a book you must pick up the topmost book in other words the one which was added last in the stack.
You cannot read a book if there is already a book placed on top of that book. You must finish the topmost book, remove it from your stack and read the one below it and keep doing this until you have read all the books.
If you buy another book then you put that book on top of that book stack and start reading this new book immediately and when you finish this new book you can go back to the previous book and start reading where you left off.

This approach follows the Last In First Out (LIFO) principle i.e. the thing which was added last is removed first.

The call stack in javascript works very similarly to our book stack.

In order to manage the execution contexts, JS engines uses a call stack. This call stack is a data structure that keeps track of information about functions being executed.

When we invoke a function then the JS Engine adds an execution context to the call stack and starts carrying out the function.
If this function also invokes another function then a new execution context is created and added on top of the call stack.
When a function is finished executing then its execution context is removed from the call stack.
If the call stack takes more space than it had been assigned then we get a 'stack overflow' error.

The call stack has been dubbed many names such as Program Stack, Control Stack, Runtime Stack, Machine Stack.

The Execution Context

When we run a Javascript code a Global Execution Context is created and pushed into the call stack. It can be imagined as the box or a container where all variables and functions are stored as key-value pairs, and the code gets evaluated and executed.

This global execution context has 2 phases or components

Memory Creation Phase or Variable Environment
Execution Phase or Thread of Execution

Memory Creation Phase

Whenever JS code is executed the global execution context (G.E.C.) goes into the memory creation phase. During this phase following things happen

a global object is created window in case of browsers, global in node.js
a global variable this is created which refers to the global object
all the variables are allocated memory and are initialized with undefined
in the case of functions the entire function is stored directly in memory.

Let's take an example

var a = "rishu"
function greet(name){
  console.log("Hello", name)
}
greet(a)

When we run this code a global execution context is created and initially, the code will go through a memory creation phase and memory is allocated to all the variables and functions.
Here the a variable is allocated memory with an undefined value. The greet function is also allocated memory but instead of undefined, the entire function is stored in that memory space.

Now the program goes into the execution phase

Execution Phase

In this phase, the code is executed line by line.

Let's go back to our example

var a = "rishu"
function greet(name){
  console.log("Hello", name)
}
greet(a)

In the above code as soon as the program encounters var a = "rishu" then variable a is assigned the value "rishu" which was initially assigned undefined

Now control goes to the next line, from lines 2 to 4 there is nothing to execute, and our function was allocated memory in the previous phase. So control goes to the last line greet(name)

greet(name) is a function invocation so another execution context or a function execution context is created and pushed inside the call stack on top of the global execution context which was pushed earlier in the call stack. This execution context also goes through 2 phases mentioned above.

During the memory allocation phase of the function execution context following thing(s) happen

name is allocated memory and initialized by undefined

Now comes the execution Phase of function execution context

Value "rishu" is stored inside that variable name as it was passed during function invocation and control reaches to next line
Next line logs Hello rishu into the console

As soon as the function greet(name) is executed the function execution context is popped out from the call stack.
Now the control goes back to the global execution context and since there is nothing more to be executed in our program this global execution context is also removed or popped out of the call stack and our Javascript program is completed executing.

Mystery Resolved

Now you can understand why we can invoke a function statement even before initializing it in our code.
It is because when we run our code then the function statements get stored in the memory before the execution begins and if we invoke our function before its initialization it will be called as it is already in our memory space.

The same goes for our variable declaration because undefined is assigned to our variable during the memory creation phase so if we log a variable before its initialization then undefined is logged in the console.

Edge Case(s)

What if we use a function expression instead of a function statement i.e we declare our function like this

var greet = function (name) {
  console.log("Hello", name);
}

In this example, we are storing an anonymous function inside our greet variable so this will behave the same as a variable, and undefined will be assigned to greet during the memory creation phase. And the function will be assigned to greet in the execution phase.

Hoisting

JavaScript Hoisting refers to the process whereby the interpreter **appears **to move the declaration of functions, variables, or classes to the top of their scope, prior to execution of the code.

Now it is very easy to understand hoisting since we know that memory is allocated to variables and functions prior to execution so we can access them before their initialization and it seems like the interpreter has moved our declarations to the top. But in reality, all these declarations are hoisted because they have been allocated memory prior to execution during the memory allocation phase

Final Words

NOTE: You might have noticed that we have declared all variables using the var keyword and we are taking examples of function statements and not storing them in let or const. This is because let and const behave differently and they are not hoisted as well, and we still haven't got answers to the questions which arose in the beginning like Why the setTimeout() functions with a timer ⏳ of say 3 seconds may or may not exactly run after 3 seconds? We'll see that in upcoming articles in this Javascript series.

per aspera ad astra

DEV Community: Rishu Patel

Async vs Defer in javascript

Introduction

<script> tag without async or defer

Async Attribute

Defer Attribute

Problem with async

Conclusion

How to create a react component library using Storybook, TypeScript, SCSS, and Rollup?

Introduction

Setting up the library

Getting Started

React & React DOM

Basic Folder Structure

Installing Typescript

Getting Storybook

Making sense of the folder structure

The stories folder

The .storybook folder

The package.json file

Adding SASS support

Creating our first component

Creating a button component

Adding styles for Button component

Creating the Button story in storybook

Bundling using Rollup

Final Words

How JavaScript Works?

Introduction

The Call stack

The Execution Context

Memory Creation Phase

Execution Phase

Mystery Resolved

Edge Case(s)

Hoisting

Final Words

`<script>` tag without async or defer

Problem with `async`

The `stories` folder

The `.storybook` folder

The `package.json` file