## Let's warm up first, shall we ?

Anyone who has ever stepped foot (*pun intended*) in the gym, knows first-hand the dread that follows when it's leg day.

Despite being well aware how important it is to train the roots, take it from the ground up for a well developed physique and strength, the lethargy is real.

Is this a technical blog brother ?  It's off-tech, but underlying lesson is from a human behind the developer window.

One look at the [Github repo](https://github.com/sanjibdey104/webdevref) for this blog and you'll understand how much I've stalled writing actual posts here. Up until now it was filled with dummy content from [Dan Abramov's Blog](https://overreacted.io/) and [Anthony Fu's Blog](https://antfu.me/posts)...quite some placeholder content 😅.

I started this blog with the intention of having a platform to document my journey and maybe even help others on the way.

> The process of writing a blog also serves as a revision strategy to help strengthen and retain your learnings, plus discover many unknown depths.

As an added bonus, it's a good enough project (*more on the technical aspects in later posts* 😉).

Yes, I've been working on [other projects](https://github.com/sanjibdey104) as well, but that is no excuse for my visible lack of intent to get out of the comfort zone and put pen on paper (*more like tapping keys on keyboard* 🤔).

## Here's the simple analogy: 

Working the upper body, crunching out those push-ups, pull-ups, feeling the pump, feels rewarding, gives an impression that we've actually worked out. Little do we bother training the lower body with the same intensity or any intensity per say. The leg day instances in our workout event loop is really messed up 😵.

On a similar note, I did plan (*ahem, ahem on the efficiency*😶), design and was developing this blog. I was working on the feel good, the upper shell of the platform, the instant gratification of implementing the design and data fetching logic. All the while, cutting corners on doing the research for that lower shell, on those piling up blog ideas, on actually drafting and publishing them.

And there it is, the *archenemy*, the *nemesis*, the *"Leg Day" of my developer life*.

Shoutout to [this blog](https://www.freecodecamp.org/news/every-developer-should-have-a-blog-heres-why-and-how-to-stick-with-it-5fd55a247fbf/) by [flavio](https://twitter.com/flaviocopes), for reflecting on the how's and why's of dev blogging. *He's a man of focus, commitment and sheer will when it comes to blogging.* 😎

So here I am, this post is me holding myself accountable, breaking the ice and doing the legwork (*admit it, I'm good at puns* 🥇). By the way, I did train legs yesterday, after 3 months. Felt great 😌.

Enough words. **I'm targeting 2-3 blogs per week**. ~~**Let's squat**~~. Ahh, I mean **let's start**. 

Ok, have a nice one. Bye.

The Leg Day

## Some context first

The stack powering this blog is [Next.js](https://nextjs.org/), [GraphCMS](https://graphcms.com/) and [Vercel](https://vercel.com/)(for hosting). Consider this post as the setting stone of a reverse chronological project walkthrough.

While setting up the blog, I initially had some placeholder content, tweaking it ever so slightly. With every push to the main branch, Vercel was auto triggering the [build step](https://vercel.com/docs/build-step), and generating static blog pages.

But once the code for the blog is set, when we've got nothing to push, what will trigger the build when we create or update a new post ? 

There comes - [Incremental Static Regeneration](https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration)(ISR). ISR hits the sweet spot between server-side rendering and static generation. A simple "revalidate" property, tells Next.js to be ready to regenerate the page after the first request comes in after a defined time. (more on this in later posts)

While searching for other ways to trigger such builds, I stumbled upon **"Webhooks"**.

## Coming to the point

*Webhooks provide a way for web applications to communicate with each other*. Sounds familiar ? Sounds just like an API, right ? We'll cover the difference shortly.

**Analogy:**
Your blog needs to stay in sync with the posts on a CMS server. You expose a webhook URL from your blog host to the CMS server. Now when you create a new post or update existing ones on the CMS, your blog host gets notified of the changes, in turn rebuilding the blog with those changes.

A robust implementation of webhooks could be seen on the cloud communication platform, [Twilio](https://www.twilio.com/). They use it to handle events like incoming SMS or calls.
Summarized snippet from [Twilio docs](https://www.twilio.com/docs/glossary/what-is-a-webhook): 

> When an event occurs, Twilio makes an HTTP request (usually a POST or a GET) to the configured webhook URL. The payload includes event details such as the incoming phone number or the body of an incoming message.

### API vs Webhook - difference in fetching

APIs are based on a process called **Polling**, where your application has to regularly request the end-point for data/updates, like you pinging Netflix to check what is the state of Money Heist Season 5's premiere.

Whereas, Webhooks are based on **Pushing**, i.e. the end-point will instantly update or *"push"* data to your app when expected events occur, like Netflix announcing to you that Season 5 will be out on September 3rd 😎.

Yes, APIs are more resource intensive than Webhooks since there is a need to constantly listen for changes. But there are many factors going into deciding on them, which are out of this post's scope.

Other platforms supporting webhooks are: GitHub, Slack, Discord etc.
A handy use case would be using [GitHub-Slack webhook integration](https://github.blog/2019-07-29-whats-new-in-the-github-and-slack-integration/) to configure an alert message for your team when events like prod deployment, PRs get triggered.

## Configuring Vercel-GraphCMS webhook integration

### Config at Vercel end

In the **Settings** console of your Vercel project config page, under **Git** section, you'll find **Deploy Hooks** space, with **Create Hook** option, then
- Give a (discernible) name to the hook
- Enter the Git Branch from which you want to trigger the build (regeneration)

![webhooks_config_vercel_end.png](https://media.graphcms.com/GHLFFQORS1CYUCFN4fza)

### Config at GraphCMS end

Under the **Webhooks** section, tap the **Create** button to launch the config window.
Plug in the Vercel Webhook URL, then select the **Triggers**, in this case: 
- Content Model (you want to listen for changes)
- Stage [draft/published] (of the content which you want to listen to)
- Action (PUBLISH/UNPUBLISH) 
which are basically the events, which when changed/updated will trigger the build at Vercel.

![webhooks_cofig_graphcms_end.png](https://media.graphcms.com/Xiq263cQYqFb5vZj9lwH)

And there you go.
Now, with every change you make to the content, it will trigger a regeneration of your blog/application.

Credit where credit is due: 
- [Vero Blog](https://www.getvero.com/resources/webhooks/)
- [Official Vercel docs](https://vercel.com/docs/more/deploy-hooks)
- [Zapier Blog](https://zapier.com/blog/what-are-webhooks/)

Have a good one. Bye.

Webhooks ft. Vercel and GraphCMS

## A quick ping

Email, Linkedin, Twitter - so, you've got these contact points on your portfolio. Won't it be great if a visitor can drop a quick message to you? Maybe a recruiter interested in having a word or someone impressed by your site would like to let you know.

That is what we'll be building today- a quick contact form using the seamless *form-to-email* API by [Formspree](https://formspree.io/), and a custom useForm hook for form validation.

## At the Formspree end

- [Register](https://formspree.io/register) with them.
- Create a **new project**
- Create a **new form** under that project with the email where you'll like to receive the form data
- On the form details page, under **Integration** section, keep a note ✍ of your **form's endpoint**, something like: https://formspree.io/f/abcdexyz

## At the React end

The *final form* of our form 😁

![final_form.png](https://media.graphcms.com/cZlsTQ6Qtul4hZ5Jf5mn)

**Note:  This form is part of my [personal portfolio](https://sanjibkumardey.vercel.app/contact). So the form attributes and CSS might look intimidating 😅. Please customize as you like.**

&nbsp;

### Form validation options:

> With web forms, the possibilities of form structure and validation mechanics could be endless. 🚀 Developing forms could be overwhelming. 🤯

Keeping it simple, here are a few possibilities:

- Use [browser default validations](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) (like *required* attribute for input fields)
- Use [Formik](https://formik.org/) library to *build forms in React, without tears* 😄
- Use [Formspree react library](https://help.formspree.io/hc/en-us/articles/360055613373-The-Formspree-React-library)
- Write a custom hook

But I came across [Anurag's Portfolio](https://anuraghazra.github.io/) where he used [custom hook](https://github.com/anuraghazra/anuraghazra.github.io/blob/develop/src/hooks/useForm.js) and since I've never created a custom hook before, thought it would be a fun learning experience.

So this hook here is a pieced-together version of Anurag's hook and [Formspree's React Form docs](https://formspree.io/blog/react-forms-2/).

🎁**There's a bonus at the end. So do read through**😉

&nbsp;

### The custom useForm hook

Let's build it piece by piece. 👷‍♀️

🌿 **The shell**
```jsx
// we'll be using axios to make a request to Formspree API
// npm install axios
import axios from "axios";
import { useState } from "react";

const useForm = () => {
  // below pieces will fit here
};

export default useForm;
```

🌿 **Form data (inputs)**

```jsx
// intial form data state
  const defaultFormData = {
    name: "",
    email: "",
    message: "",
  };
  const [formData, setFormData] = useState(defaultFormData);

  // tracking and storing the field errors as key-value pairs
  const [errors, setErrors] = useState({});

  // handle onChange event for the input fields
  const handleInput = (e) => {
    const { name, value } = e.target;
    setFormData({ ...formData, [name]: value });
  };
```

🌿 **The regex (against which we'll validate those fields)**

```jsx
  // someone much smarter than me wrote these 😅
  const regexValidations = {
    email:
      /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/,
    name: /^[a-zA-Z\s]*[^\s]$/gim,
    message: /^[\w\d][^<>/\\&]*$/gim,
  };
```

🌿 **Field validations**

```javascript
const validateInputs = () => {
    // generating an array from the "keys" of the formData object
    const inputs = Object.keys(formData);

    // looping through each field and running the validation checks
    inputs.forEach((input) => {
      if (!formData[input]) {
        // empty field check
        errors[input] = `Your ${input} is required`;
      } else if (!regexValidations[input].test(formData[input])) {
        // testing against the corresponding regex
        errors[input] = `Please enter a valid ${input}`;
      } else {
        // empty value otherwise
        errors[input] = "";
      }
    });
    setErrors((prevState) => ({ ...prevState, ...errors }));
    
   // generate array using the values of the error object and check for  empty("") strings, since Boolean("") returns false
// if length === 0, return true(i.e. proceed with form submission), else false(i.e. prevent form submission and render validation errors)
    return Object.values(errors).filter(Boolean).length === 0;
  };
```

> Object.filter(Boolean), passes each item to Boolean(), which coerces them to true or false (depending on whether its [truthy](https://developer.mozilla.org/en-US/docs/Glossary/Truthy) or [falsy](https://developer.mozilla.org/en-US/docs/Glossary/Falsy)), and we keep the true ones. 
Credit: [Michael Uloth's article](https://michaeluloth.com/filter-boolean)


🌿 **Render validations errors (if any) for respective fields**

```javascript
const renderErrorMsg = (field) => {
 if (errors[field]) return <p className="error-msg">{errors[field]}</p>;
};
```
![formspree_form_validation_errors.png](https://media.graphcms.com/KctfPR3RAeckYHXlwVJQ)


🌿 **Handle Form Submission**

```javascript
  const handleFormSubmit = (e) => {
    e.preventDefault();

    if (!validateInputs()) {
      // to prevent form from submitting if errors exists
      return;
    }

    // if no errors then, try submitting the form
    setServerState({ submitting: true });
    axios({
      method: "POST",
      url: `https://formspree.io/f/${your-form-endpoint}`,
      data: formData,
    })
      .then((res) => handleServerResponse(true, "Thank you for the message"))
      .catch((res) => handleServerResponse(false, res.response.data.error));
  };
```

🌿 **The return object**

```javascript
// we'll import these in our form component 
  return {
    formData,
    handleInput,
    handleFormSubmit,
    errors,
    serverState,
    renderErrorMsg,
  };
```

&nbsp;

### Form component

```jsx
// destructuring the object returned from useForm hook
const {
  formData,
  handleInput,
  handleFormSubmit,
  serverState,
  renderErrorMsg,
} = useForm();

<form
  className="quick-message-form"
  onSubmit={handleFormSubmit}
  noValidate 
// to prevent browser from doing default validations when submitting the form
>
  <label htmlFor="name">Name: </label>
  <input
    type="text"
    id="name"
    name="name"
    placeholder="Bond, James Bond"
    value={formData.name}
    onChange={handleInput}
    aria-label="name"
  />
  {renderErrorMsg("name")}
  <label htmlFor="email">Email: </label>
  <input
    type="text"
    id="email"
    name="email"
    placeholder="bond007@mi6.com"
    value={formData.email}
    onChange={handleInput}
    aria-label="email"
  />
  {renderErrorMsg("email")}
  <label htmlFor="message">Message: </label>
  <textarea
    name="message"
    id="message"
    cols="30"
    rows="5"
    placeholder="Can I have one Vesper Martini, please? Shaken, not stirred."
    name="message"
    value={formData.message}
    onChange={handleInput}
    aria-label="message"
  ></textarea>
  {renderErrorMsg("message")}
  <button
    type="submit"
    id="dispatch-btn"
// prevent user from clicking the button while form is submitting
    disabled={serverState.submitting}
    aria-label="form submit button"
  >
    Dispatch
  </button>
</form>
```

&nbsp;

### Component Style

- Global styles(https://github.com/sanjibdey104/portfolio-v1/blob/main/styles/globalStyles.js)
- [Form Styles](https://github.com/sanjibdey104/portfolio-v1/blob/main/components/custom/ContactForm.js)

&nbsp;

**You must be wondering: *"Hey, how do we know whether the form was submitted successfully or not"***

### 🔥 Here's the bonus: 
Custom Toast Component for those successful or failed server responses.
Place this after the form component.

```js
<>
// form component here
// given that we have the status we pass the serverState as prop
{serverState.status && <ToastMessage serverState={serverState} />}
</>
```

![formspree_form_success_toast.png](https://media.graphcms.com/M7MFlLubR1qK5wVl8xUY)

```jsx
import React, { useEffect, useState } from "react";
import styled from "styled-components";

const StyledToastMessage = styled.div`
  width: 15rem;
  height: 2rem;

// positioned relative to the page
  position: fixed;
  top: 50%;
  right: 1rem;

  display: flex;
  align-items: center;
  justify-content: center;

  border-radius: 0.5rem;
  padding: 0.5rem;
  text-align: center;
  font-size: 0.85rem;
  font-weight: 500;
  color: white;

/* initially the component is off the screen*/
  transform: translateX(120%);
  transition: transform 200ms ease-in-out;

  &.error-response {
    background-color: #ff3333;
  }

  &.success-response {
    background-color: #5cb85c;
  }

  &#show {
    transform: translateX(0);
  }
`;

const ToastMessage = ({ serverState }) => {
// handling toast state
  const [showToast, setShowToast] = useState(false);

  useEffect(() => {
    setShowToast(true);

// the toast disappears after 3 sec
    const toastTimeout = setTimeout(() => {
      setShowToast(false);
    }, 3000);
    return () => {
      clearTimeout(toastTimeout);
    };
  }, []);

  return (
    <StyledToastMessage
      id={showToast ? "show" : null}
      className={
        serverState.status.isSubmitSuccessful
          ? "success-response"
          : "error-response"
      }
    >
// populate with success or error message 
      {serverState.status.msg}
    </StyledToastMessage>
  );
};

export default ToastMessage;
```

Quite a long read, but I hope you liked it. Go ahead, implement it in your own project and share if you find it helpful.

Have a good one. Take care. Bye. 👋

Contact form ft.  Formspree API and useForm hook

So I fell off the consistent blogging wagon. 👏

Only if you consider 3 posts as consistency 😂. But hey, I was trying nonetheless 🤔.

But this time, thankfully the reason was not me being lazy, rather bridging the missing links.

JavaScript is a programming language. (Mic Drop 🎤😎⚡, what a revelation !!!)

And that means, way too many moving parts to take a hold of and as a self-taught, self-paced beginner the task feels even more gigantic.

Being "self-taught" in itself is a huge undertaking, plus being "self-paced" could make things even trickier, without proper planning it could easily rob you off the expected progress. And that is where it went sideways for me. 

I've stalled, a little too long, getting into the weeds of the JavaScript engine mechanics. I've had a surface level understanding of concepts like Execution Context, Scope, Hoisting, Closures etc. 

> Swam across the shallows, but never the depth of it all.

So this past week, I've been dismantling the JavaScript machinery into those very pieces, reading, researching and soaking in the logic behind its quirks and fortes.

What comes next?

I've decided to document the whole journey, the process, the learning, document it all as a series, building it up one step at a time. Projecting the thought process, and conceptual understanding from a beginner's perspective.

Over the past week, in my quest for that wholesome understanding of the language, I came across several blogs and video walkthroughs that collectively gave me that "Aha moment". And I'll be doing my bit to share those resources and my takeaways, with the community out there. Hopefully helping beginners like me steer their journey a bit better.

Plus, it will be a token of thanks to those wonderful developers-teachers who have put so much effort into making us fall in love with this amazing language.

This is the series initiation post. Starting tomorrow I'll be posting those blog pieces. So let's explore the behind the scenes, those beautiful concepts that JavaScript keeps abstracted from us.

This is me sharing my journey of truly embracing JavaScript.

Have a good one.
Take care.
Bye.

Embracing JavaScript: Series initiation post

### Just like any artist, we start with the blank canvas

So, this is our HTML file.

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- meta tags -- >
    <title>JS Playground</title>

    <script src="app.js" ></script>
  </head>
  <body>
  </body>
</html>
```

We've got the HTML shell, and a script "app.js", which looks like:

```jsx
// app.js

```

Yep, it's blank.
But guess what, the JS engine has already started working.

The moment the script gets loaded, the engine gets to work, and the first thing it does is: **Create an Execution Context**.

Context basically refers to the space/environment in which the JS engine evaluates and executes a piece of code. (quite literally how we phrase, ["in the context of"](https://dictionary.cambridge.org/dictionary/english/context))

> JS engine reads our code line by line, weaves through it like a single thread and executes it, that's why we call JavaScript a **single-threaded, synchronous programming language**.

🔥 Execution contexts are of following three types: 

- Global Execution Context (default)
- Function Execution Context
- Eval Execution Context (need not bother for now)

In the above scenario, with a blank script, we get the default execution context, i.e. the Global Execution Context. 

### Let's start painting now

🔥 Now, there are two phases while creating an execution context:

1. Creation Phase
2. Execution Phase

### 1. Creation Phase

In this phase, we go another level deep into something called a **[Lexical Environment](https://262.ecma-international.org/6.0/#sec-lexical-environments)**. 

In this environment, JS does a spell, called [**Hoisting**](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting).
It scans through our code line-by-line and captures all the variable and function declarations, allocates them some space in the memory and initializes them with some values.

What those values are?

For primitive values, it's
- "undefined" if variable declared using "var"
- left uninitialized if variable declared using "let" or "const"

For functions, the entire function definition is stored

🔥 Going deeper, we've got three primary components under lexical environment:
- Environment record
- Outer environment reference
- "this" keyword binding

📌 **Environment Record**

Now environment record in itself has two types: Declarative and Object. You can [read more here](https://stackoverflow.com/questions/20139050/what-really-is-a-declarative-environment-record-and-how-does-it-differ-from-an-a).

All in all, it basically keeps a record of all the variable and function declarations. 
This record is a reflection of "Hoisting" we've briefed above.

📌 **Outer environment reference**

As your code grows, so does the variables, functions and nesting. So, JS makes sure that every Execution Context has a reference to its surrounding, in case some variable is outside its own scope (we'll discuss in later posts).

```javascript
let item = "Tesla";
function elonSays() {
console.log(`Go buy a ${item}`);
}
```
"elonSays" function has reference to its outer lexical environment. And since the "item" variable is not in function scope, so JS knows to look for the "item" variable in the outer environment which happens to be the global context in this case.

*For a function, the outer reference will be the "Global Context", however for the global context itself, it will be "null" since nothing sits over it. *

📌 **"this" keyword binding** 

*Now, the "this" keyword need separate discussion altogether. Let's keep it simple for now.*

"this" keyword refers to an object. Now what that object is, depends on the context.
Consider this 😂 example:

```javascript
// 1. global context
console.log(this);  // displays the "window" object

// 2. function called in global context 
function whatIsThis() {
  console.log(this); // displays the "window" object
}

// 3. function as an object property
let agent = {
  name: "Jason Bourne",
  showPosition: function () {
    return this;
  },
};
console.log(agent.showPosition); // displays the "agent" object
``` 

### 2. Execution Phase

All those hoisted variable will be assigned corresponding values, and the function(s) will be executed.

```javascript
var character = "Draco Malfoy";
function greetCharacter() {
console.log(`Hello, ${character}`);
}
greetCharacter(); 

// upon hoisting
// var role = undefined;
// entire greetWorld function definition stored in memory

// during execution phase
// var role = "Draco Malfoy";
// executes the function and prints "hello world"
```

### 😇 Let's summarize the whole flow with an example.

```javascript
let characterOne = "Sirius Black";

showFavoriteCharacter();

function showFavoriteCharacter() {
  let characterTwo = "Severun Snape";
  console.log(`Everyone loves ${characterOne} and ${characterTwo}`);
}
```

**Global Execution Context**

Creation phase

- Environment record (hoisting occurs) 

let characterOne; // uninitialized 

showFavoriteCharacter //holds the entire function definition
- outer env reference: null
- "this" keyword: window object

Execution phase

- Environment record let character = "Sirius Black";
- outer env reference: null
- "this" keyword: window object

*Now, as we hit the "showFavoriteCharacter" function, a totally new execution context will be created.*

**Function Execution Context**

Creation phase
- Environment record (hoisting occurs) 

let characterTwo; // uninitialized
- outer env reference: Outer Lexical Environment
- "this" keyword: window object

Execution phase
- Environment record 

let character = "Severus Snap";
- outer env reference: Outer Lexical Environment
- "this" keyword: window object

With that outer reference, the function is able to locate the "characterTwo" variable in the global context. And finally, it logs: *"Everyone loves Sirius Black and Severus Snape"*

This whole process of creation and execution occurs for each and every function that gets called throughout your script, no matter how nested it gets.

&nbsp;

🤔 **But, wait a minute**. How does JavaScript handle those bazillion execution contexts, that too with deep nesting?

🔥 Well, JS maintains the flow of execution using the **Execution Call Stack**, or simply **Call Stack**.
A stack basically follows the **LIFO principle i.e. Last In First Out**.

The process goes like this:

- When the script runs, default Global Execution Context (**GEC**) gets created and pushed to the stack
- When it finds a function call/invocation, a Function Execution Context (**FEC**) gets created and pushed on top of GEC.
- And if that function calls another one, a new EC gets created and pushed on top of it.
Once the function returns or the execution finishes, the stack is cleared starting from the top.

```javascript
outer();

function outer() {
  //some instructions
  inner();
  function inner() {
    // some instructions
  }
}
```

During the execution phase, the call stack would look like this,

[2] inner() 

[1] outer()

[0] GEC

Once each function execution finishes, its FEC popped off the stack, and ultimately the GEC is removed as well.

And there you go. Hope you got some clarity on how the execution stack is created and handled.

&nbsp;

 📚💡 **Resources referenced for this blog:**

- [Codesmith playlist](https://www.youtube.com/watch?v=exrc_rLj5iw)
- [Sukhjinder Arora's blog post](https://blog.bitsrc.io/understanding-execution-context-and-execution-stack-in-javascript-1c9ea8642dd0)
- [Akshay Saini's Playlist](https://www.youtube.com/watch?v=iLWTnMzWtj4&list=PLlasXeu85E9cQ32gLCvAvr9vNaUccPVNP)

&nbsp;

**🍕Teaser**

*Did you see how we've called outer() function even before defining the function itself. Well, it's all because of **Hoisting and Scope**. Topics that we'll discuss in the upcoming posts.*

&nbsp;

Until then, if you have any queries, suggestions or corrections, drop a comment below.

Have a good one. Take care. Bye. 👋

Embracing JavaScript: Blank script, Execution Context and the Call Stack

Scope refers to the accessibility of concerning variables, functions or objects in a particular part of code.

As JS interpreter weaves through our code (in a single thread) and executes it line by line, it checks whether the variables and invoked functions are properly defined.

🔥 Scopes can be broadly categorized as: 

🌿 **Global scope** - Any declaration outside a function or block (curly braces). This is the outermost scope.

```jsx
let agent = "James Bond"; //global scope
```

🌿 **Local scope** - This is turn is of two types:

- **Function scope**: Inside a function
```js
function callAgent() {
  var agent = "Ethan Hunt";
  console.log(agent);
}
```
- **Block scope**: Inside a pair of curly braces (like if statements and for loops, or standalone braces)
```js
if(true){
  console.log("Bitter but truth");
}
```

It might seem confusing at first since function too have curly braces like blocks do. But there is a separation of concern, which we'll see below. So you could summarize scope types as Global, Function/Local and Block.

Now when it comes to variables in JavaScript, we can declare one using: **var, let or const.**

- Declared with **var: function/local or global scope**
- Declared with **let or const: block scope**

🌿 Guess the scope of below variables:

```jsx
let firstAvenger = "Captain America";

{ //standalone block
	var alimightyAvenger = "Thor";
}

function greetAvenger() {
	const wizardAvenger = "Dr. Strange";
}
```

1. "firstAvenger" ⇒  global scope, since it's out in the open.
2. "alimightyAvenger" ⇒ global scope. Yes, it's in a block but "var" is not bound to a block, it is global in this case.
3. "wizardAvenger" ⇒ local scope. Yes, it is in a function, but remember from the [previous post](https://webdevref.vercel.app/posts/embracing-javascript-blank-script-execution-context-and-the-call-stack), a function has its own new execution context. Hence, within the curly braces of the function, the variable is in the local scope.

&nbsp;

 🔥 Talking about functions and execution contexts, they can be nested, like below. Here we observe something called **lexical scope**.

```jsx
function outer() {
	inner();
	function inner() {
	}
}
```

&nbsp;

🚧 Recollection Alert 🚧 

In the [last post](https://webdevref.vercel.app/posts/embracing-javascript-blank-script-execution-context-and-the-call-stack), we discussed **"Lexical Environment"**, which is basically the environment that a function exists in, including both the inner and outer space. And when we talk about scope in that context, we refer to the scope as **lexical scope.**

Lexical Environment has a component that holds the reference to its outer scope. Meaning, during the execution phase, if the JS engine is unable to locate a variable used inside a function, it can go look for it outside.

Lexical scope is what makes this possible:

```js
let wizard = "Dumbledore";
function hogwardsNews() {
	console.log(`We lost professor ${wizard}.`); 
}
hogwardsNews(); // "We lost professor Dumbledore."

//-------------------------------Nested functions----------------

function hogwardsNews() {
	let wizard = "Severus Snape";
	function finale() {
		console.log(`We lost professor ${wizard} as well.`);
	}
	finale(); // "We lost professor Severus Snape as well."
}
```

&nbsp;

📌 The main takeaway of **lexical scope** is that, it **is one way.** Meaning, **we can access outer variables (in the global scope or outer function scope) from a function but not vice versa.**

```jsx
console.log(`${wizard} is gone.`); // ReferenceError: wizard is not defined
function hogwardsNews() {
	let wizard = "Voldemort";
}

//------------------------In case of nested functions----------------------

function hogwardsNews() {
	console.log(`We lost ${wizard}.`); // ReferenceError: wizard is not defined
	tournamentNews();
	function tournamentNews() {
		let wizard = "Cedric Diggory"
	}
}
```

&nbsp;

🔥 See what we did there with **"tournamentNews" function ⇒ called it before defining**.

Well, it means, it's time to **bridge the gap between Scope and Hoisting.**

> Where the variables and functions are declared dictates where they will be accessible in our code.

When our script runs, the JS engine creates a Global Execution Context(**GEC**), and when functions are invoked we get Function Execution Context (**FEC**).

EC creation happens over two phases:

- Creation Phase
- Execution Phase

> **It is during the creation phase that we observe Hoisting.**

In the creation phase, the engine scans every variable declaration and function declaration and hoists them to the top of their context. [Hoisting](https://www.merriam-webster.com/dictionary/hoist) literally means *to lift*.

This dictates, how our code will behave in the execution phase, like whether it runs properly or throws an exception.

&nbsp;

🌿 There is a catch, which we will explore through the below examples:

> Only declarations are hoisted, not initialization.

That means, during the creation phase:

- **For variables**:
JS allocates them a location in memory labelled with their identifier names but doesn't bother with their actual values. 
```js
let anime = "Demon Slayer";  // identifier name: "anime"

// creation phase - hoisting
// memory        ||  value
// [01x001]anime ||   depends on var,let const
```

- **For functions**:
JS allocates them a location in memory labelled with their identifier names, but the content of that location is a reference to the actual function definition

```js
function favAnime() { console.log("demon slayer") }

//creation phase - hoisting
// stack memory     || value
// [01x002]favAnime || [08xx01]

// heap memory || value
// [08xx01]    || function favAnime..... (whole definition)
```

&nbsp;

Keeping that in mind, let's consider the following example:

```jsx
let place= "Hobbit Village";
lordOfTheRings();
function lordOfTheRings() { // some code }
```

Both, "*place" variable and "lordOfTheRings" function* gets hoisted to the top of GEC.

We can imagine it as:

```jsx
// creation phase
// Hoisting
let place;
lordOfTheRings // holds a reference to the "lordOfTheRings" function definition

place = "Blade Runner 2049";
lordOfTheRings() // JS will fetch the function definition from heap memory and execute the function 
```

&nbsp;

**🚧 Word of caution 🚧**

> No, JS doesn't physically move those variables or functions to the top of the code. This is just so you can have a photo memory of how to explain the concept.

Since **function definition gets hoisted, we can invoke it beforehand**. But, **what about the variables?**

&nbsp;

🔥 Given that we have multiple ways to define variables, so there is a catch in how they are hoisted.

📌 **var keyword**

```jsx
console.log(fruit); // undefined
var fruit = "banana";
```

📌 **let and const keyword**

we get the following reference error

```jsx
console.log(fruit); // "ReferenceError: Cannot access 'counter' before initialization
let fruit = "orange";
```

So in the creation phase, during hoisting

- **"var"** variables are allocated space in stack memory and initialized with a special value "undefined". Not a string. It is a [primitive data type](https://developer.mozilla.org/en-US/docs/Glossary/Primitive).
- **"let" and "const"** variables are allocated a space in stack memory, but not initialized, hence the "initialization error".

&nbsp;

🌿 Another catch is when we use [**function expressions**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function) and [**arrow functions**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions) 

```jsx
// this is function declaration
function favFruit() { //some code }

// this is function expression
let favFruit = function() { //some code }
const favAnime = () => { //some code }
```

> In a function expression, we use the "function" keyword, or simple braces for arrow function expressions, to define an anonymous function and assign it as a value to a variable. They are treated as any other value of a variable.

Here's the case, 

```jsx
favFruit(); // TypeError: favFruit is not a function
var favFruit = function () { //some code }

//During hoisting, this the state
var favFruit = undefined;
favfruit() // means we are trying to do undefined(), hence the error
```

&nbsp;

🔥 All these errors and chaos 😵 is due to **Temporal Dead Zone (TDZ)**.

Sounds fancy, but it simply refers to the zone/space that exists in the time between, variable declaration and initialization.

In the context of hoisting think of it as the time between variable hoisting and initialization of the variable.

```js
// TDZ starts
// let favAnime; // uninitialized when hoisited
console.log(favAnime); // variable has been declared, thus memory allocated, but not initialized yet

let favAnime = "Demon Slayer";  // variable is initialized, marks the end of TDZ
```

&nbsp;

> As we could clearly see that hoisting can create some valid confusion. It is important to understand but advised not to exploit it as a convenience. Try calling the functions and using the variables after defining them.

&nbsp;

🔥 To hit it home with try this example:
```js
var food = "grapes";
thoughts();

let thoughts = function () {
  console.log(`Original food: ${food}`);
  var food = "oranges";
  console.log(`New food: ${food}`);
};
```
This example is taken from the free trial videos of [Andrei Neagoie's Advanced JavaScript Course](https://www.udemy.com/course/advanced-javascript-concepts/). Validate your answer with the video.

&nbsp;

📚💡 **Resources referred for the blog:** 

- [JavaScriptTutorial's blog](https://www.javascripttutorial.net/javascript-hoisting/)
- [Akshay Saini's Playlist](https://www.youtube.com/watch?v=Fnlnw8uY6jo&list=PLlasXeu85E9cQ32gLCvAvr9vNaUccPVNP)
- [Sitepoint's blog](https://www.sitepoint.com/demystifying-javascript-variable-scope-hoisting/)

&nbsp;

🍕 **Teaser**

Did you observe these terms we used above: **Stack and Heap memory**. Let's discuss that in our next post.

&nbsp;

Leave your queries, suggestions or corrections in the comments below.

Have a good one. Take care. Bye. 👋

Learn. Share. Grow.

recent posts 👇

Embracing JavaScript: Scope and Hoisting

Embracing JavaScript: Blank script, Execution Context and the Call Stack

Embracing JavaScript: Series initiation post

Contact form ft. Formspree API and useForm hook