DEV Community: Amit Barletz

The Amplication Plugin System

Amit Barletz — Tue, 02 May 2023 14:00:58 +0000

The plugin system is one of the many exciting features released in version 1.0.0 of Amplication. As an open-source company, we're driven by the developer community's needs. The idea to develop a plugin system came from a specific call from developers: to have more flexibility in the generated application.

Some of the most debated topics among software developers today are best practices, principles (like SOLID, DRY, and YAGNI), and whether to use opinionated frameworks and libraries. Those familiar with our generated application software have probably noticed it is very opinionated and follows the NestJS best practices. However, we want our platform to be the answer for everyone—and we want to stay responsive to the developer community. So we sat down to consider best practices for enabling the extension and manipulation of Amplication-generated applications to make them less opinionated and more flexible. The result? Amplication's new, community-driven solution for plugin system architectures.

Let's dive into what plugins are, explore how Amplication handles them, showcase how we build them, and explore some of the considerations required to create an effective, error-free plugin.

Plugins in Amplication

Plugins are software additions that allow the customization and enhancement of computer programs, applications, and web browsers. Amplication's plugin system allows us to add new features or manipulate our generated application's behaviors. Our Data Service Generator (DSG) gathers all the data that the user configures in the UI or CLI, including entities and their fields, roles, permissions, and services settings. The DSG then uses these values as inputs for its functions; each function is responsible for code generation in a specific area, such as CreateEntityController, CreateEnitityResolver, CreateServerDockerCompose, and more.

To build this framework for plugins, we've exposed each function to plugin developers, providing all the data and context known at that point and allowing the system to manipulate the data and impact the event's results.

Before and After Functions

All events share the same interface, which contains two functions: before and after. These functions are responsible for different steps in an event's lifecycle. Here's how they look:

export interface PluginEventType<T extends EventParams> {
  before?: PluginBeforeEvent<T>;
  after?: PluginAfterEvent<T>;
}

For each event, the type of EventParams is different, providing access to relevant data for the specific event.

export interface EventParams {}

export type PluginBeforeEvent<T extends EventParams> = (
  dsgContext: DsgContext,
  eventParams: T
) => Promisable<T>;

export type PluginAfterEvent<T extends EventParams> = (
  dsgContext: DsgContext,
  eventParams: T,
  modules: Module[]
) => Promisable<Module[]>;

In the before and after functions, developers can access the context and the event parameters. We use the context to gather data shared between events. The event parameters are used to manipulate the default behavior by passing values that differ from the default.

The after function also gives us access to the generated modules. This parameter can be helpful when a developer wants to restructure the generated modules into a different folder structure.

Amplication will continue generating code as normal when no lifecycles event is provided and no parameters are changed.

Utility Functions: `skipDefaultBehavior`

In addition to the specific parameters required for each event, we also provide a global context object that can help the developer access other data they need, such as the list of entities, roles, other services in the project, and all files generated thus far. It also has a util property consisting of utility functions. One of these utility functions is skipDefaultBehavior.

context.utils.skipDefaultBehavior = true;

The default behavior won't execute when the skipDefaultBehavior is set to true in the before function, so developers must provide their logic. Developers can do so after the skip in the before or after functions.

It's important to remember that using skipDefaultBehavior without providing an alternative functionality can cause unexpected behavior—for example, the skipped event could generate files imported by other files, so it must be used wisely and carefully. As Uncle Ben said, "With great power comes great responsibility."

Events Hierarchy

It's essential to consider the execution order of the events in the DSG (Figure 1.) There are two main events in the DSG service: one for the server generation and the other for the admin-ui creation.

These main events include other sub-events to create the server and admin-ui's files. (In Amplication's source code, these files are sometimes called modules.) The internal events within the server and admin-ui events are synchronous, so the execution order of plugin code must be accounted for when developing them.

Figure 1: Execution order of the events in the DSG

Let's break down this image into three component types:

A single DSG event with a plugin wrapper is indicated by a rectangle with no forward arrows. The title represents the corresponding event name.
"Create message broker" is a function with a plugin wrapper that executes other events of the message broker creation. As in the previous category, the title corresponds to the event name.
Resources creation (in a gray rectangle "for each entity") is a function that executes the events of the resources' creation, such as services, controllers, and resolvers.

A Quick Breather

Let's take a breather before we go to how to develop a plugin. Deep breath in, 1... 2... 3... 4... 5..., deep breath out, 1... 2... 3... 4... 5...

alt="A breathing exercise"
width="287" height="311"
loading="lazy"
style="margin-left: auto; margin-right: auto;">

If you're interested in the Amplication Plugin System and would like to see more of what the platform offers. In that case, we invite you to check out the Amplication GitHub repository.

We've built our platform with open-source technologies, and your support is crucial to our success. If you find our platform helpful, we would greatly appreciate it if you could take a moment to 🌟 us on GitHub. Your support helps us to continue developing and improving the platform for everyone. Additionally, if you want to contribute to the project, we welcome pull requests and issues on our GitHub repository. We appreciate your support!

Developing a Plugin

As we've seen, plugins are complex beasts with interdependent parts that must be kept in mind during their development process, including wrappers, before and after lifecycle events, event parameters, context, skipDefaultBehavior, and event hierarchy. Understanding the importance of each part can help us develop an effective and error-free plugin.

Amplication's Development Process

In this last section, we want to share the plugin development process used by our team at Amplication. Before development begins, we take the following steps:

Generate a service with Amplication.
Apply the changes required manually on the resulting source code that Amplication generated:
- Add any missing functionality.
- Manipulate the existing functionality.
Create a PR to see the changes, and use the result to design the plugin.
- Determine which events are needed. For example, if we use a new npm package, we must update the package.json file.
- Decide how to use events with the before and after lifecycle functions. We know that CreateServerPackageJson is one of the first events that run, so we must capture that event in the before function and add the new npm package.
- Take into consideration exception errors caused by the plugin's functionality or limitations.

Plugin Development Workflow in Action

To illustrate this development workflow, let's look at the MySQL plugin. But first, let's review the functionality of a database connection:

We already have the functionality of a database connection using Prisma as an ORM.
Prisma supports MySQL as a provider; change the provider on the Prisma schema accordingly.
We use environment variables for the Prisma schema database's URL and the DockerCompose values; we change the environment variables and their values where needed.

Now, let's translate the above steps to events:

Figure 2: The register method for Events

During Step 3 of the development workflow, we encountered an unexpected behavior: Prisma's MySQL provider does not support lists of primitive types. In the following function (beforeCreateServer), we will account for this limitation in Prisma by throwing an error when one of the entities' fields type is MultiSelectOptionSet. Here is an example of a use case where the plugin should throw an error:

Figure 3: The beforeCreateServer event

`CreateServerDotEnv`: `before`

On this event, we send our event parameters, specifically the environment variables for the MySQL database. As a result, the .env file will be generated with the default variables it already holds and our environment variables.

`CreateServerDockerCompose`: `before`

We also send our event params on this event, this time the YAML properties and values for the MySQL database. As a result, the docker-compse.yml file is generated so that the MySQL properties will replace the PostgreSQL properties.

`CreateServerDockerComposeDB`: `before`

This event is responsible for generating the docker-compose.db.yml file, which contains the docker image of the PostgreSQL database. Here we have an excellent example of skipDefaultBehavior usage. We can skip this file generation and provide different functionality—in this case, a separate file—later, in the after function.

Figure 4: The beforeCreateServerDockerComposeDB event

`CreateServerDockerComposeDB`: `after`

After skipping the default behavior in the before function, we provide our docker-compose.db.yml file on this event.

Figure 5: The afterCreateServerDockerComposeDB event

`CreatePrismaSchema`: `before`

This event is responsible for manipulating the following part of the Prisma schema:

Figure 6: The dataSource object

EventParams

We use the event params to:

Change the data source name from Postgres to MySQL
Change the provider from Postgresql to MySQL

(CreateServerDotEnv handles the DB_URL)

Summary & Conclusion

Amplication's Plugin System allows developers to extend or alter the code generation process to include support for additional features or to make any changes to the default "flavor" of the generated application. It is an excellent way for our developer community to extend our platform safely and for our users to adjust the generated code to their specific needs. When writing these lines, over a dozen plugins are already available for Amplication, and our community and users are currently developing others.

In this blog, we reviewed what Plugins are and their architecture and gave a real-world example of creating a new Plugin.

If you liked the idea behind our Plugins and want to try writing one, please join our Discord community, where you can get help from fellow community members and our core team. We are friendly, and we like to help the community generate more useful plugins. If you develop a Plugin and we publish it, we will make sure to send you cool Swag 🙂.

Closures - What, How and Why

Amit Barletz — Mon, 28 Dec 2020 16:42:28 +0000

☑️ What

When it comes to closures or any complex topic, I find that the most effective way to learn is through an example. However, to explain what closures are I must use some complex concepts like lexical environment and scope chain which, by the way, I might have promised in the previous article that I will cover. So, it is a good opportunity to resolve that promise. 😇

Let's have a look at this example code and analyze it.

function a() {
  const name = 'Shai';
  return function b() {
    const age = 32;
    return function c() {
      const city = 'Tel-Aviv';
      return `${name} is ${age} years old amd he lives in ${city}`
    }
  }
}
// a() // function b
// a()() // function c
a()()(); // "Shai is 32 years old amd he lives in Tel-Aviv"

When function 'a' gets invoked, the JS engine creates a new execution context and pushes that function to the call stack.

With the call stack, the JS engine can keep track of where the code is in its execution, or in other words, which execution context is currently running.

Execution context tells us which lexical environment (lexical means at compile time, where the function is written) is currently running and in every execution context, we get the 'this' keyword, arguments and variable environment.

In our example, we first call function 'a' => a(). As a result, a new execution context is created and function 'a' gets pushed to the stack.
The lexical environment of function 'a' is the global environment because it located in the global environment.

Then, we call function 'a' again => a()(), a new execution context is created and function 'b' gets pushed to the stack.
Function 'b', however, wrapped by function 'a', therefore its lexical environment is function 'a' and the global environment.

In the third call => a()()() function 'c' gets returned, a new execution context is created, and function 'c' gets pushed to the stack.
Function 'c' located inside function 'a' and function 'b', therefore its lexical environment is function 'a', function 'b' and the global environment.

In other words, function 'c' is lexically scoped inside function 'b', which is lexically scoped in function 'a'.

Lexical scope is the available data and variables where the function was defined (NOT where it was called) and it determines our available variables.

Variables defined inside a function are not accessible from outside the function, which means that the variables in function 'b' and function 'c' are not accessible to function 'a', and the variables in function *'c' are not accessible to function *'b'.

But, function 'b' has access to global variables and the variables which were defined in function 'a', and function 'c' has access to the global variables,
variables which were defined in function 'b' and function 'a'.

I know, it's very confusing, so I made a chart which I hope makes it clear.

This is possible thanks to the scope chain.

When in the call stack, we are in the execution context of function 'c', which his variable environment is 'city' and it is lexically scoped inside function 'b'
and function 'a' - it has access to the variables of those functions.

return `${name} is ${age} years old and he lives in ${city}`

So, when the JS engine gets to this line above, first it searches for the 'name' variable in the local variable environment of function 'c',
when it does not find the variable, the JS engine goes up on the scope chain to function 'b'. The 'name' variable is not declared in function 'b',
so we go again up on the scope chain to function 'a', where we find the declaration of the variable 'name'.
This works the same with variable 'age'. About the 'city' variable, as its part of the variable environment of function 'c'', there is no need to search
it in the outside world - no need to goes up on the scope chain.

⛔️ Pause: I know, you feel I am throwing on you a lot of concepts, while I did not even begin to explain what closures are, but I promise that soon it will be clear.

With that knowledge, let's make a closure with closures and, finally, explain what they are.

Closure is the combination of a function and the lexical environment from which it was declared. It allows a function to access variables from an enclosing scope or environment even after it leaves the scope in which it was declared.

After function 'a' gets invoked, pushed to the stack and popped of the stack, its variable environment ('name') remains in memory,
which means it does not get collected by the garbage collector because another function - function 'c' has a reference to it.

The same thing happens with function 'b', and that's why even after those functions get popped off the stack, function 'c' still has access, through the scope chain, to the 'name' and 'age' variables.

The JS engine knows, before we get to the line in the code in which we call function 'a', which function has access to which variables and save those variables.

NOTE: if we have another variable in function 'b', which is not in use by function 'c', the JS engine will not save it in the closure box and it is gonna be garbage collected.

const something = 'something';

☑️ How

By 'how' I mean how we create a closure (or how to use it).

We can create closures due to the fact that in JavaScript, functions are first-class citizen, which means that functions can be returned from another function and functions can be passed as an argument to another function.

Therefore, in order to use a closure, define a function inside another function and expose it by returning or passing it to another function.

If we take a look again at our example, we can see the structure of closures:

a function that gets returned from another function, while the returned function has access and uses variables from the outer function variable environment.

☑️ Why

Closures have 2 main benefits:

1. Memory efficiency

In the following example, we have a function that creates very big array every time it gets called (because nothing is referencing that function and its variable, so it gets collected by the garbage collector);

function heavy(index) {
  const bigArr = new Array(9000).fill('😈');
  console.log('created!');
  return bigArr[index];
}

heavy(889); // 'created!' '😈'
heavy(889); // 'created!' '😈'
heavy(889); // 'created!' '😈'

With closures, we have a way to only create the array once:

function notHeavy() {
  const bigArr = new Array(9000).fill('😈');
  console.log('created again!');
  return function(index) {
      return bigArr[index];
  }
}
const closureHeavy = notHeavy();
closureHeavy(889); // 'created again!' '😈'
closureHeavy(889);
closureHeavy(889);

The function 'notHeavy' gets called and because its inner anonymous function uses one of its variables: 'bigArr', this variable does not get collected by the garbage collector. As the anonymous function located lexically inside the 'notHeavy' function, it has access to its variables and can goup on the scope chain.

Now, we can call 'notHeavy' just once, save the result in a variable, and with that variable, call the function again (the anonymous function).

The array will be created only once (and we can confirm it by running the code above and see that we get the console.log only once), and that's why
it saves memory.

2. Encapsulation

const makeBomb = () => {
  let pauseTime = 0;
  const passedTime = () => pauseTime++;
  const totalPauseTime = () => pauseTime;
  const launch = () => {
    pauseTime = -1;
    return '💥';
  }
  setInterval(passedTime, 1000);

  return {
    totalPauseTime
  }
}

const bombBtn = makeBomb();
bombBtn.totalPauseTime(); // 0
bombBtn.totalPauseTime(); // 30 - the seconds that have passed until I run the function again

With encapsulation, we can hide information that is unnecessary to be seen or manipulated by the outside world.

This follows the principle of least privilege - a big security principle when it comes to programming, where you don't want to give just anybody access to your API.

We don't want anyone to be able to launch a bomb 💥, so we don't expose the 'lunch' method. We only expose the 'totalPauseTime' method by creating a closure and returning it.

Thanks for reading. I hope you now know better what closures are, how to create and use closures, and why use closures.

Link to the original post:
https://syntactic-sugar.netlify.app/closures

How not to be afraid of the 'this' keyword

Amit Barletz — Wed, 23 Dec 2020 17:08:07 +0000

To start talking about the 'this' keyword, we should first understand where it comes from.
When a function (or method) gets invoked, it has 2 phases: the creation phase, and the execution phase.

There are a lot of things to discuss when it comes to those phases, and a lot of concepts like execution context, lexical environment, variable environment, scope and scope chain (But don't worry, I will discuss them in depths in the next article). Therefore, for simplicity, in this article, we only need to know that the value of 'this' keyword is NOT static.

It depends on how the function is called, and its value is only assigned when the function is actually called.

What do I mean by "It depends on how the function is called"? glad you asked!
In JavaScript, there are different ways in which functions can be called and as a result, the 'this' keyword gets different value:

1. Simple function call:

In this case, the 'this' keyword points to the global object - the window,
but in 'strict mode' the 'this' keyword will be undefined.

'use strict'
console.log(this); // window

// es5 way for writing function
const calcAgeES5 = function(birthYear) {
  console.log(new Date().getFullYear() - birthYear);
  console.log(this); // undefined (without the 'use strict' - window)
}

calcAgeES5(1991);

// es6 way for writing function
const calcAgeES6 = birthYear => {
  console.log(new Date().getFullYear() - birthYear);
  console.log(this); // window
}

calcAgeES6(1991);

2. Method:

A method is a function attached to an object. In this case the 'this' keyword points to the object on which the method is called, or in other words, it points to the object that is calling the method.

const marry = {
  birthYear: 1988,
  calcAge: function() {
    console.log(this) // marry
    return new Date().getFullYear() - this.birthYear;
  }
}
marry.calcAge();


const joe = {
  birthYear: 2010
}

joe.calcAge = marry.calcAge;
joe.calcAge(); // this => joe

In the following example we save the 'calcAge' method called on 'marry' to a variable called 'func'. When we will log 'func' we will see the method printed to the console:
ƒ () {
return new Date().getFullYear() - this.birthYear;
console.log(this);
}

But, on a strict mode, when we will call func(), the 'this' keyword of that execution context will be undefined because it's a regular function call
that is not attached to any object. Without the 'use strict' the 'this' keyword will be the window object.

'use strict'
const func = marry.calcAge;
console.log(func) // log the function
func(); // this => undefined

3. Arrow functions:

Arrow functions do not get their own 'this' keyword, they get the 'this' keyword of the surrounded function (the parent function).
It's called the lexical 'this' keyword because it simply gets picked up from the outer lexical scope.
In the following example, the parent scope is the global scope because the 'marry' object lives in the global scope, therefore the 'this' keyword is the window.

const marry = {
  firstName: 'Marry',
  birthYear: 1988,
  calcAge: function() {
    console.log(this) // marry
    return new Date().getFullYear() - this.birthYear;
  },
  greet: () => {
    console.log(this); // window
    console.log(`Hello ${this.firstName}`);
  }
}

marry.greet(); // Hey undefined

NOTE: variables declared with 'var' create properties on the global object, therefore in this case where we declared firstName with 'var' and we will call 'marry.greet()', we will get 'Hello Tomas'. It happens because when the greet method gets called it searches for 'firstName' variable in its local scope, does not find it, and go up in the scope chain until it finds it on the window object, there we have window.firstName because of the declaration with 'var'.

var firstName = 'Tomas';
marry.greet(); // Hello Tomas

The way to fix the problem with the 'greet' method is to write it in a form of a regular function and not an arrow function.

const marry = {
  firstName: 'Marry',
  birthYear: 1988,
  calcAge: function() {
    console.log(this) // marry - the object that call the method
    return new Date().getFullYear() - this.birthYear;
  },
  greet: function() {
    console.log(this); // marry
    console.log(`Hello ${this.firstName}`); // Hello Marry
  }
}

marry.greet();

Function inside a method:

const marry = {
  birthYear: 1988,
  calcAge: function() {

    const isMillenial = function() {
      console.log(this.birthYear >= 1981 && this.birthYear <= 1996); // undefined
    }
    isMillenial();
    return new Date().getFullYear() - this.birthYear;
  }
}
marry.calcAge();

'isMillenial' is a regular function call even though it happens inside of a method, and as we have learned earlier in this article inside a regular function call the 'this' keyword is the global object - window (and undefined in 'use strict' mode). There are 2 solutions for the "problem":

i. Outside the 'isMillenial' function save the 'this' to a variable:

const self = this; // self or that
const isMillenial = function() {
  console.log(self.birthYear >= 1981 && self.birthYear <= 1996); // true
}
isMillenial();

ii. Use arrow function which takes the 'this' of his surrounded environment, which in this case is 'calcAge' method, which its this' keyword is 'marry' object

const marry = {
  birthYear: 1988,
  calcAge: function() {

    const isMillenial = () => {
      console.log(this.birthYear >= 1981 && this.birthYear <= 1996); // true
    }
    isMillenial();
    return 2020 - this.year;
  }
}
marry.calcAge();

4. The 'new' operator

To explain the new operator we first need to understand what is a constructor function.
A constructor function is a function that used as a blueprint to create objects, therefore when we call the function, it must be with the new operator
and when we write a constructor function, the name should start with a capital letter.

Constructor functions are used to stimulate classes which we have now in ES6 but as syntactic sugar.
An arrow function cannot be a function constructor because as I have stated, it does not have its own 'this' keyword.
Only function declaration and function expression can be a constructor function.

const Person = function(firstName, birthYear) {
  console.log(this); // Person {}
  this.firstName = firstName;
  this.birthYear = birthYear;

  // NEVER DO THIS
  this.calcAge = function() {
    console.log(2020 - this.birthYear);
  }
}

const amit = new Person('Amit', 1991);
console.log(amit); // Person {firstName: "Amit", birthYear: 1991}

When we call a constructor function with the new operator there are 4 steps that happen behind the scenes

new empty object is created
the function is called and 'this' keyword point on the newly created object.
the newly created object has a link to the prototype (on our example: Person).
the new object created on step 1 returned from the constructor function.

NOTE: you should never create a method inside a constructor function because if that function has many methods, each object that builds based on it, would carry around all the methods. Instead, we should use prototype inheritance, but this is a topic for another article.

5. call, apply, bind

Help us to set the 'this' keyword manually

const lufthansa = {
  airline: 'Lufthansa',
  iataCode: 'LH',
  bookings: [],
  book(flightNum, name) {
    console.log(`${name} booked a seat on ${this.airline} flight ${this.iataCode}${flightNum}`);
    this.bookings.push({
      flight: `${this.iataCode}${flightNum}`,
      passengerName: name
      })
  }
}
lufthansa.book(239, 'John Lennon');
lufthansa.book(447, 'Amy Winehouse');

Now, let's say we have another airline, with different properties but it still needs the book method.
We can copy and paste that method, but it's bad practice. What we should do is to store the method in a variable, so we can
use it in other places. The reason why we can do it like that is that in js functions are first-class citizens.

const book = lufthansa.book();
book(123, 'Marge Simpson'); // Cannot read property airline of undefined

Because 'book' is a regular function call, the 'this' keyword points to undefined (in strict mode).

The way to fix it is to tell JS explicitly what the 'this' keyword should be and here come call, apply, and bind.

call && apply: functions that their first argument is the one we want the 'this' keyword to point on. The other arguments are the argument which the function we call on the call or apply methods takes. The difference between call and apply is that apply gets the argument as an array (or an array-like object) and 'call' gets them individually.

const elal = {
  airline: 'Elal',
  iataCode: 'EL',
  bookings: []
}

book.call(elal, 123, 'Marge Simpson'); // 'Marje Simpson' books a seat on Elal flight EL123
book.apply(elal, [789, 'Alice Cooper']); // 'Alice Cooper' books a seat on Elal flight EL789

bind: also allows us to manually set the 'this' keyword for any function call. The difference is that bind does not immediately call the function, instead it returns a new function where the 'this' keyword set to the provided value.

const bookEl = book.bind(elal);
bookEl(123, 'Marge Simpson') // 'Marje Simpson' books a seat on Elal flight EL123

// OR we can provide arguments (partial application)
const bookEl123 = book.bind(elal, 123);
bookEl123('Marge Simpson') // 'Marje Simpson' books a seat on Elal flight EL123
bookEl123('Diana Ross') // 'Dianna Rose' books a seat on Elal flight EL123

There are cases when we do not mind what the 'this' keyword is, but we still use bind, for example in a partial application when we preset parameters.
Be aware that the argument you want to preset must be the first argument;

const addTax = (rate, value) => value + value * rate;

const addTax30 = addTax(null, 0.3);
addTax30(200);

6. Event listener:

In an event handler function, the 'this' keyword always points to the DOM element that the handler function is attached to.

<button class="buy">Buy a new plane</button>

const lufthansa = {
  airline: 'Lufthansa',
  iataCode: 'LH',
  bookings: []
}

lufthansa.planes = 300;
lufthansa.byPlane = function() {
  console.log(this); // <button class="buy">Buy a new plane</button>
  this.planes++;
  console.log(this.planes); // NaN
}

document.querySelector('.buy').addEventListener('click', lufthansa.byPlane);

If we will run this code, the line we log 'this' to the console will give us the reference to the DOM element the handler function is attached to,
therefore at the line, we log Lufthansa's planes to the console we will get NaN.

The way to fix it is to use the bind method because in event listener we don't want to immediately call the function, we just pass a reference to the function
which will be called when the event accrues.

document.querySelector('.buy').addEventListener('click', lufthansa.byPlane.bind(lufthansa));

Conclusions:

The 'this' keyword isn't static. It depends on how the function is called, and its value is only assigned when the function is called.

In this article we have covered many cases when the 'this' keyword gets different values, so to summarize the article I am going to tell you what the 'this' keyword will never be:

'this' will never point to the function in which we are using it.
'this' will never point to the variable environment of the function.

As a side note, I would like to share with you one of the reasons I decided to write the first blog post about the 'this' keyword.
When I started learning JavaScript and going to my first interviews I was asked a lot about the 'this' keyword,
and even I went through that topic before every interview when the interviewer asked me a question about the 'this' keyword,
I got confused and nervous and did not get it right.

Thanks for reading, hope you enjoyed and learned something new or at least feel more comfortable with the 'this' keyword now.

😇 Link to the original blog post at my blog:
https://syntactic-sugar.netlify.app/this