Forem: Pranav

Hoisting Isn't Even Real

Pranav — Sat, 20 May 2023 08:51:29 +0000

One of the most famous interview topics - HOISTING, isn't even real.

Yes, you heard that right.

The word 'hoist' wasn't even used in the official ECMAScript specifications until the year 2015. It was first mentioned in the ECMAScript 6 specification, which was published in June of that year.

DEFINITION

If you search on Google, this is what you get

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, before the execution of the code. Hoisting is not a term normatively defined in the ECMAScript specification.

Please refer to it here.

And even there they've correctly mentioned that Hoisting is not a term normatively defined in the ECMAScript specification.

MISINFORMATION

shinobi;
sensei;
var shinobi = 'naruto';    // line 3
var sensei = 'kakashi';    // line 4

So, based on the definition of hoisting, JS should be able to anticipate all variable declarations, as seen in lines 3 and 4, regardless of their position within the scope and move them to the top of the scope before the code execution begins.

Something like this:

// before execution
var shinobi;
var sensei;

shinobi;
sensei;
shinobi = 'naruto';
sensei = 'kakashi';

Which is not what happens.

JavaScript doesn't move things around the way we might expect it to. Because how would it magically be able to look ahead & find only the declarations in the very first pass?

To be able to do that, you would need to perform complex processing on later tokens in the code block until reaching its end. And theoretically extract any declarations if any are encountered and move them to the top. And guess what that magical processing's called - PARSING!

So, Hoisting is just a shorthand, a convenient explanation to describe this magical behavior without getting into the nitty-gritty details.

REASON

All this misunderstanding occurs because JS execution is a 2-pass process i.e. parsing/compilation & execution. But people tend to think of JS execution as one pass process rather than two.

If you think of it as 2 passes. You can easily explain this magical behavior with the help of Lexical Scope.

Unfortunately, I can't cover it now because of the vastness of the topic but you may refer this as the best resource.

Function Scopes and IIFE Pattern

Pranav — Tue, 09 May 2023 19:20:19 +0000

WHY

Consider you've written code like the below at some point. We've declared a var and hope that it still has the same value. Well, right now it looks good.

var ninja = 'Naruto';

// ...

console.log(ninja); // Naruto

But say after a few months a jr. dev comes along and unknowing try to make a change like this.

var ninja = 'Naruto';

// ...

var ninja = 'Sasuke';
console.log(ninja); // Sasuke

console.log(ninja); // Sasuke -- oops!

So, you can easily see the issue here.
We have a naming collision problem.

You may think, we should just use const there. But the problem is not if the variable can be reassigned (because the developer if not aware could just modify your const to var anyways) but we have a naming collision problem.

So, the problem is: We have a problem where 2 different people wanna use the same semantic name for their purposes.

PSEUDO FIX

Since the problem could be thought of as mainly arising due to the declaration of the variable in the same scope. So, the natural fix coming to mind would be, to make use of different scopes, and one simple way to do so could be by wrapping a function around it.

var ninja = 'Naruto';

function anotherNinja() {
    var ninja = 'Sasuke';
    console.log(ninja); // Sasuke
}
anotherNinja();
console.log(ninja); // Naruto

So, now those vars don't seem to collide anymore and the code seems to work well. But now the problem is, we have a named function in the same scope.

So it seems, we didn't solve the name collision problem, we just shifted it to a different variable name.

REAL FIX - IIFE

var ninja = 'Naruto';
(function anotherNinja() {
    var ninja = 'Sasuke';
    console.log(ninja); // Sasuke
})();
console.log(ninja); // Naruto

So, this code pattern you see is called an IIFE pattern i.e. Immediately Invoking Function Expression, which does exactly what it sounds like.

Using IIFE, we're creating a new scope and immediately invoking it.

Another use case: when you want to turn statements into expressions

Consider below example:

var ninja;
try {
    ninja = fetchNinja();
}
catch (err) {
    console.log(err);
}

If you wanna do something like this, since try-catch is a statement it doesn't work in an expression position.
You can do something like this:

var ninja = (try {
    ninja = fetchNinja();
}

catch (err) {
    console.log(err);
})();

Summary

Try to follow "The principle of least privilege" whenever possible.

The principle of least privilege is the idea that any user, program, or process should have only the bare minimum privileges necessary to perform its function.

Leverage the power of function scopes and IIFE patterns to enjoy the benefits of the principle like:

Avoid naming collisions
Restrict code access
Ability to freely refactor code

API Gateway Responses and Handling Authorizer Responses

Pranav — Thu, 04 May 2023 01:44:39 +0000

Intro

I have added a token-based Lambda Authorizer for all my backend services deployed on API Gateway. I wanted the user to be signed out if the authorizer responds with a 401 (Unauthorized) or 403 (Access Denied) error.

This is how my code looked like for the authorizer lambda:

const jwt = require('jsonwebtoken');

exports.handler = function (event, context, callback) {
  const token = event.authorizationToken?.split(' ')[1];

  if (!token) {
    callback('Unauthorized'); // Return a 401 Unauthorized response
  }

  const data = jwt.verify(token, process.env.SECRET, (err, data) => {
    if (err) {
            // Return a 403 Access Denied response
      callback(null, generatePolicy('user', 'Deny', event.methodArn, {"messageString":"Invalid token"}));
    }
    return data;
  });

  callback(null, generatePolicy('user', 'Allow', event.methodArn, data));
};

// Help function to generate an IAM policy
const generatePolicy = function (principalId, effect, resource, data) {
  const authResponse = {};

  authResponse.principalId = principalId;
  if (effect && resource) {
    const policyDocument = {};
    policyDocument.Version = '2012-10-17';
    policyDocument.Statement = [];
    const statementOne = {};
    statementOne.Action = 'execute-api:Invoke';
    statementOne.Effect = effect;
    statementOne.Resource = resource;
    policyDocument.Statement[0] = statementOne;
    authResponse.policyDocument = policyDocument;
  }

  // Optional output with custom properties of the String, Number or Boolean type.
  authResponse.context = {
    ...data,
  };
  return authResponse;
};

After this, I used to get error logs on my client apps, but I could not access the response object to check the response's status code.

I needed to determine if an error was caused by my authorizer (resulting in a 401 or 403 status code) or by my API endpoint lambdas. The issue was that the response was being caught as a fetch error in the catch block instead of returning a response with the expected status code and message that I could handle properly.

Additionally, I guess it was even giving me a CORS error, which I wasn't able to understand why.

Solution

After quite a bit of searching, I found out that to receive proper handleable responses, I would need to configure the API Gateway Responses section in the API Gateway.

Here, you can see all of the responses the API Gateway is capable of handling.

Add the CORS headers in the response header to receive proper handleable responses and configure the response templates as you need.

In my case, this is how I configured my Access Denied:

#Note: Here, the messageString comes from the context data that we are sending from our Authorizer function that we defined previously.

.
.
.
if (err) {
    // Return a 403 Access Denied response
  callback(null, generatePolicy('user', 'Deny', event.methodArn, {"messageString":"Invalid token"}));
}
.
.
.
  authResponse.context = {
    ...data,
  };
}

For more info:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#api-gateway-gatewayResponse-definition