Forem: Sam Abaasi

Avoiding Unsafe Calls in JavaScript and React Projects with ESLint

Sam Abaasi — Sun, 29 Dec 2024 17:10:23 +0000

Avoiding Unsafe Calls in JavaScript and React Projects with ESLint

📜✨ In modern JavaScript and React applications, it's common to encounter runtime errors caused by accessing properties on undefined or null values, or calling methods on undefined arrays or objects. These issues can disrupt user experience and make debugging a nightmare. In this article, we'll identify the common issues and provide an ESLint configuration to mitigate them effectively. 🌟💻

🌟✨ In our React or React Native projects, because we are not using TypeScript, we sometimes forget to write safe code. These unsafe codes can lead to many issues in production, like crashing React Native apps, frustrating users, and complicating maintenance. Let's dive into these common issues and how to solve them. 🚨🚀💔

Common Issues with Unsafe Calls

1. Accessing Properties on `undefined` or `null` 🌟🔍✨

Problem:

Accessing a property on an object that is undefined or null causes a runtime error:

const user = undefined;
console.log(user.name); // ❌ Runtime Error: Cannot read property 'name' of undefined

Solution:

Solution 1: Use optional chaining (?.).

const name = user?.name;

Solution 2: Employ a default fallback.

const name = user ? user.name : 'Default Name';

Solution 3: Ensure initialization before access.

const user = { name: 'Default Name' };

2. Calling Methods on `undefined` or `null` ✋📉📋

Problem:

Calling methods like .map() or .filter() on an undefined array throws an error:

const items = undefined;
items.map((item) => console.log(item)); // ❌ Runtime Error: Cannot read property 'map' of undefined

Solution:

Solution 1: Verify that the variable is an array.

if (Array.isArray(items)) {
  items.map(item => console.log(item));
}

Solution 2: Provide a default array.

const items = someValue || [];
items.map(item => console.log(item));

Solution 3: Use the nullish coalescing operator (??).

const items = possibleItems ?? [];

3. Invoking Undefined Functions ⚙️⚠️🚫

Problem:

Trying to call a function that might be undefined:

const handler = undefined;
handler(); // ❌ Runtime Error: handler is not a function

Solution:

Solution 1: Check existence before invocation.

if (typeof handler === 'function') {
  handler();
}

Solution 2: Assign a no-op default function.

const handler = passedHandler || (() => {});

4. Destructuring Undefined or Null Objects 📦❌🔓

Problem:

Destructuring properties from an undefined object results in an error:

const obj = undefined;
const { name } = obj; // ❌ Runtime Error: Cannot destructure property 'name' of undefined

Solution:

Solution 1: Use optional chaining with defaults.

const { name = 'Default Name' } = user || {};

Solution 2: Validate before destructuring.

if (user) {
  const { name } = user;
}

5. Accessing Non-Existent Array Elements 🚫📋📊

Problem:

Accessing elements of an undefined array causes an error:

const arr = undefined;
const first = arr[0]; // ❌ Runtime Error: Cannot read property '0' of undefined

Solution:

Solution 1: Provide a default fallback.

const first = (arr && arr[0]) || 'Default Value';

Solution 2: Initialize arrays properly.

const arr = arr || [];
const first = arr[0];

6. Invalid Array/Function Usage 🛑📝

Problem:

Using array methods like .map() or .filter() on undefined values or objects:

const numbers = undefined;
numbers.filter((n) => n > 0); // ❌ Runtime Error: Cannot read property 'filter' of undefined

Solution:

Solution 1: Always validate inputs for array functions.

if (Array.isArray(numbers)) {
  numbers.filter(n => n > 0);
}

Solution 2: Return a safe result if input isn't valid.

const results = Array.isArray(numbers) ? numbers.filter(n => n > 0) : [];

7. Insufficient Conditional Checks 💡🔒

Problem:

Failing to validate conditions strictly can lead to bugs, such as relying on falsy values. For example, if conditions expecting a boolean might incorrectly evaluate other types like undefined or 0:

const obj = {};
if (obj.prop) {
  // Executes even if obj.prop is `undefined`, leading to unexpected behavior
}

Solution:

Solution 1: Use strict equality comparisons.

if (obj.prop === true) {
  console.log('Do something');
}

Solution 2: Coerce values explicitly for intended behavior.

if (!!obj.prop) {
  console.log('Do something');
}

Solution 3: Define explicit conditions in your code.

if (typeof obj.prop === 'boolean' && obj.prop) {
  console.log('Safe conditional execution');
}

Using ESLint to Avoid Unsafe Calls 🚀🔒✅

To catch these issues during development, we can leverage ESLint with specific rules. Below is an ESLint configuration that will flag unsafe calls and suggest fixes. 🛠️🔍🌟

ESLint Configuration 📜💻🛡️

Add the following rules to your .eslintrc.js or ESLint configuration file:

module.exports = {
  parser: '@typescript-eslint/parser', // If using TypeScript
  plugins: ['@typescript-eslint'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:@typescript-eslint/recommended-requiring-type-checking',
  ],
  parserOptions: {
    ecmaVersion: 2020, // or later
    sourceType: 'module',
    project: './tsconfig.json', // Type-aware linting
  },
  rules: {
    // 1. Disallow accessing properties on undefined/null
    '@typescript-eslint/no-unnecessary-condition': 'warn',

    // 2. Enforce optional chaining where needed
    'no-unused-expressions': ['warn', { allowShortCircuit: true }],

    // 3. Disallow unsafe calls (functions on undefined/null)
    '@typescript-eslint/no-unsafe-call': 'error',

    // 4. Disallow unsafe member access (accessing props on undefined/null)
    '@typescript-eslint/no-unsafe-member-access': 'error',

    // 5. Catch invalid destructuring of undefined or null
    '@typescript-eslint/no-unnecessary-condition': 'warn',

    // 6. Catch invalid array/function usage (e.g., map/filter on undefined)
    'consistent-return': 'warn',

    // 7. Enforce stricter conditional checks
    '@typescript-eslint/strict-boolean-expressions': [
      'error',
      {
        allowNullableObject: false,
        allowNullableBoolean: true,
        allowNullableString: true,
        allowNumber: true,
        allowAny: false,
      },
    ],

    // Additional rules for clarity and safety:
    'no-implicit-coercion': ['warn', { allow: ['!!'] }],
    'no-unreachable': 'error',
    '@typescript-eslint/no-non-null-assertion': 'error',
  },
};

Explanation of Rules 💡⚙️🌐

@typescript-eslint/no-unnecessary-condition: Flags unnecessary conditions or unhandled potential undefined or null values. ⚠️
no-unused-expressions: Ensures that short-circuited logic like someObject && someObject.doSomething is avoided unless explicitly necessary. 🚀
@typescript-eslint/no-unsafe-call: Prevents unsafe function calls on non-functions. ❌
@typescript-eslint/no-unsafe-member-access: Flags attempts to access properties on potentially undefined values. ✋
consistent-return: Enforces consistent return types in functions to avoid returning invalid or undefined values. 💾
@typescript-eslint/strict-boolean-expressions: Strengthens conditional expressions by preventing implicit coercion. 🔒
@typescript-eslint/no-non-null-assertion: Disallows the unsafe ! operator used to bypass null/undefined checks. 🚫

Installing Required Dependencies 📦🔧🔍

To enable these rules, ensure you have the necessary ESLint plugins and parsers installed:

npm install eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-dev

Integrating ESLint with VSCode 🖥️🚦🌈

1. Install the ESLint Extension:

Search for "ESLint" in the VSCode marketplace and install it. ✨

2. Enable Auto-Fixing:

Add the following to your settings.json:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"]
}

3. Run ESLint:

Add an npm script to run ESLint:

"scripts": {
  "lint": "eslint . --ext .js,.jsx,.ts,.tsx"
}

Then, run npm run lint to catch issues. 🚀

Conclusion 🌟🚀📘

By implementing the above ESLint rules and practices, you can catch and fix unsafe calls before they become runtime errors. 🎉🌈 This approach will improve the reliability and maintainability of your JavaScript and React projects. 🌍⚙️✨

🚀How JavaScript Works (Part 10)? Class

Sam Abaasi — Thu, 26 Oct 2023 10:29:23 +0000

JavaScript classes have become a fundamental part of modern JavaScript development. Introduced in ES6, they provide a convenient way to create and manage objects and their behaviors. However, understanding the full potential of JavaScript classes, beyond their syntactic sugar, is essential for writing efficient and maintainable code. In this article, we'll delve into JavaScript classes. We'll explore the syntax, inheritance, and the nuanced aspects of working with classes. We'll also discuss best practices, including how to avoid common pitfalls. Additionally, we'll take a closer look at the concept of auto-binding methods, which aims to address the challenge of maintaining the correct this context when working with class methods. Let's dive in!

The Class Syntax
Extending Classes
Relative Polymorphism
Beyond Syntactic Sugar: A Closer Look
- Preserving this
- Understanding Prototype
The Challenge of Maintaining this Context
The Concept of Auto-Binding
The Problem with Auto-Binding Methods
- The Hacky Solution
- Violating JavaScript's DNA
The Danger of Permanent Hacks
Best Practices: Embracing the Full Power of Classes
Conclusion
Sources

The Class Syntax

In JavaScript, classes are defined using the class keyword. They can have names, but it's worth noting that classes can also be expressions and even anonymous. The class syntax supports the declaration of constructors and methods without the need for commas between them. For example:

class Workshop {
    constructor(topic) {
        this.topic = topic;
    }

    ask(question) {
        console.log(`Welcome to the ${this.topic} workshop! ${question}`);
    }
}

const deepJS = new Workshop("JavaScript");
deepJS.ask("What happened to 'this'?");

Extending Classes

JavaScript classes support inheritance through the extends clause. When a class extends another class, it inherits the methods and properties of the parent class. You can also define additional methods in the child class. Here's an example:

class ChildWorkshop extends Workshop {
    speakUp() {
        console.log(`Speaking up in the ${this.topic} workshop!`);
    }
}

const childJS = new ChildWorkshop("Advanced JavaScript");
childJS.ask("What's the superclass?");
childJS.speakUp();

Relative Polymorphism

Relative polymorphism is a concept that allows child classes to override methods defined in the parent class. JavaScript's class system supports this through the super keyword. It enables child classes to refer to methods in the parent class with the same name. This is particularly useful for customizing behavior. For instance:

class ChildWorkshop extends Workshop {
    speakUp() {
        super.ask("Can I ask questions?");
        console.log(`Speaking up in the ${this.topic} workshop!`);
    }
}

Beyond Syntactic Sugar: A Closer Look

Preserving `this`

One of the significant points is the behavior of this within class methods. In JavaScript, the this keyword is not auto-bound to class methods, and they behave just like regular functions. This means that if you pass a class method to a function like setTimeout, it will lose its this binding. To preserve this, developers often use hardbound methods or arrow functions, which can lead to unnecessary complexity and performance overhead.

Understanding Prototype

The class system in JavaScript is built upon the concept of prototypes. Methods and properties are defined on the prototype, not on instances. However, when you assign a function directly to an instance, it no longer exists on the prototype. This practice can lead to creating separate copies of functions for each instance, which is inefficient and diverges from the core principles of class-based JavaScript.

The Challenge of Maintaining this Context

One of the common challenges developers face when working with JavaScript classes is ensuring that the this context remains consistent when calling class methods. This is particularly crucial when you pass class methods as callbacks or use them in asynchronous operations like setTimeout. Without proper binding, the this context can become unpredictable.

Here's a simple example that illustrates this issue:

class Workshop {
  constructor(teacher) {
    this.teacher = teacher;
  }

  ask(question) {
    console.log(`${this.teacher} asked: ${question}`);
  }
}

const deepJS = new Workshop("Kyle");
const askFunction = deepJS.ask;

askFunction("What is auto-binding?");

In this example, when we call askFunction, the this context inside the ask method is no longer bound to the deepJS instance. It results in an error because this.teacheris undefined.

The Concept of Auto-Binding

Auto-binding methods refer to a mechanism that automatically maintains the correct this context for class methods, without the need for explicit binding. While JavaScript doesn't provide native auto-binding, developers often come up with solutions to achieve it.

Here's an example of how you can implement a basic auto-binding utility for class methods:

function autoBindMethods(classInstance) {
  const prototype = Object.getPrototypeOf(classInstance);
  const methodNames = Object.getOwnPropertyNames(prototype);

  methodNames.forEach((methodName) => {
    if (typeof classInstance[methodName] === 'function') {
      classInstance[methodName] = classInstance[methodName].bind(classInstance);
    }
  });
}

class Workshop {
  constructor(teacher) {
    this.teacher = teacher;
    autoBindMethods(this); // Automatically bind class methods
  }

  ask(question) {
    console.log(`${this.teacher} asked: ${question}`);
  }
}

const deepJS = new Workshop("Kyle");
const askFunction = deepJS.ask;

askFunction("What is auto-binding?");

In this modified example, we use the autoBindMethods function to automatically bind all class methods when an instance is created. This way, the ask method maintains the correct this context even when used as askFunction.

The Problem with Auto-Binding Methods

The Hacky Solution

In discussions about auto-bound methods, a potential solution has been suggested. The idea is to replace actual methods on class prototypes with getters. These getters would dynamically create hard-bound versions of the methods on the fly and cache them in a WeakMap. When you access a method through the getter, you automatically get a hard-bound version. This is a complex and unconventional approach that fundamentally changes the behavior of JavaScript functions.

Violating JavaScript's DNA

JavaScript functions are known for their dynamic nature. Auto-binding methods, while seemingly convenient, contradict the fundamental principles of JavaScript's functions. Attempting to force JavaScript into the mold of classes from other languages leads to complex and hacky solutions like the one described above. It doesn't align with JavaScript's core philosophy of flexibility and dynamic behavior.

The Danger of Permanent Hacks

As has been wisely noted, "There's nothing more permanent than a temporary hacker." The danger of introducing such hacky solutions is that they might become permanent parts of the language. Once developers start using them, it's challenging to reverse the trend, even if they contradict the core principles of the language.

Best Practices: Embracing the Full Power of Classes

To make the most of JavaScript classes, it's crucial to embrace their full capabilities. Here are some best practices to consider:

Leverage Prototypes: Embrace the prototype chain and avoid assigning functions directly to instances. This ensures efficient memory usage and maintains the dynamic nature of classes.

Avoid Hardbound Methods: While hardbound methods and arrow functions can preserve this, they might not be necessary. Embrace the dynamic nature of JavaScript and leverage this without overcomplicating your code.

Keep Classes Dynamic: Don't limit the class system's dynamic flexibility. If you need dynamic, flexible structures, consider alternatives like the module pattern, which has been available for over two decades and provides a robust solution for many use cases.

Conclusion

JavaScript classes are a powerful tool for creating and managing objects in your code. While they provide a convenient syntax, it's essential to understand their inner workings and nuances fully. In this article, we explored the syntax of JavaScript classes, their inheritance mechanism, and the concept of relative polymorphism using the super keyword. We also delved into the discussion surrounding auto-binding methods, which aim to address the challenge of maintaining the correct this context in class methods.

It's important to note that JavaScript's class system is built upon the concept of prototypes, where methods and properties are defined on the prototype rather than directly on instances. To make the most of JavaScript classes, we recommend leveraging prototypes, avoiding hardbound methods or arrow functions when they are unnecessary, and keeping classes dynamic.

While the idea of auto-binding methods has been considered, it's important to avoid overly complex solutions that contradict the core principles of JavaScript's dynamic behavior. By embracing the dynamic nature of JavaScript's class system and maintaining the flexibility it offers, you can write more efficient, maintainable, and robust JavaScript code.

Understanding JavaScript classes beyond their syntactic sugar empowers developers to make the most of this fundamental feature, creating better software and enhancing the JavaScript ecosystem.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 9)? Arrow functions and lexical this

Sam Abaasi — Thu, 26 Oct 2023 10:25:36 +0000

The advent of ES6 brought us many exciting features, and among them, arrow functions stood out as a concise and elegant way to write functions. However, while arrow functions have been embraced for their brevity, they come with certain quirks that can be a double-edged sword for developers.

The Anonymous Nature of Arrow Functions
The Inferred Purpose
The Power of Descriptive Function Names
The Readability Factor
Arrow Functions in the Context of this
The Essence of Lexical this
Arrow Functions and the new Keyword
The Curly Brace Confusion
The Parent Lexical Scope
The Right Tool for Lexical this Behavior
Conclusion
Sources

The Anonymous Nature of Arrow Functions

Arrow functions are inherently anonymous, unlike traditional functions with a distinct name. This anonymity can impact code readability, making it challenging for developers to quickly discern the purpose of a function. Consider this arrow function:

const getId = people.map(person => person.id);

As Kyle Simpson aptly put it, **"The only way to figure out what an arrow function is doing is to read its function body." **This lack of a name can obscure the function's intention, leading to potential confusion for you and other developers working on the code.

The Inferred Purpose

Proponents of arrow functions argue that their purpose is self-evident. However, it's essential to remember that the purpose of an arrow function is inferred rather than explicitly expressed through a well-chosen name. You are required to deduce the function's intent by examining its code, which can sometimes lead to ambiguity.

The Power of Descriptive Function Names

In contrast, when you use a named function, you provide a clear and explicit label for the function's purpose. For example, consider the alternative using a function declaration:

function getIdFromPerson(person) {
  return person.id;
}
const ids = people.map(getIdFromPerson);

In this revised code, the function getIdFromPerson conveys its purpose without ambiguity. It's evident that this function retrieves the id property from a person object. Descriptive names enhance code readability and maintainability, making it easier for you and your team to understand and work with the codebase.

The Readability Factor

While arrow functions offer brevity, they can sometimes compromise readability. Self-explanatory code, where the purpose of a function is evident from its name, often proves invaluable. Arrow functions' shorter syntax may initially appear more straightforward, but the brevity can come at the cost of understanding and maintainability. Moreover, arrow functions come in various syntax variations, leading to potential confusion in certain contexts.

Arrow Functions in the Context of this

However, it's crucial to acknowledge that arrow functions bring a unique characteristic called "lexical this behaviour." This behaviour can be immensely valuable in specific situations.
Consider this example:

const workshop = {
    topic: "JavaScript",
    ask: function () {
        setTimeout(() => {
            console.log(`Welcome to the ${this.topic} workshop!`);
        }, 1000);
    },
};
workshop.ask(); // Outputs: Welcome to the JavaScript workshop!

In this case, the ask method of the workshop object contains an arrow function passed to setTimeout. Surprisingly, within the arrow function, the this keyword correctly points to the workshop object. This phenomenon is the essence of "lexical this behavior."

Now, let's dive deeper into what "lexical this" means:

An arrow function does not define a this keyword. In fact, it doesn't have a this keyword at all; it treats this like any other variable.

The Essence of Lexical this

In essence, lexical this means that an arrow function will keep climbing up the scope chain until it locates a function with a defined this keyword. The this keyword in the arrow function is determined by the function containing it. In the example, it looks up one level in scope and finds the ask function.

This understanding is crucial because it helps you avoid incorrect thinking, which can lead to bugs in your code. By thinking in alignment with JavaScript's design and the language specification (the spec), you can ensure that your code behaves as expected.

The JavaScript language specification confirms that an arrow function does not define local bindings for arguments, super, this, or new.target. This specification is a key point of reference, and adhering to it eliminates misconceptions and potential issues in your code.

Arrow Functions and the new Keyword

One fascinating aspect of arrow functions is their behavior concerning the new keyword. If you recall from earlier in this series, the new keyword takes precedence over a hardbound function. That means, for some unusual reason, if you call new on a hardbound function, it can override the hard binding and become the new object. However, this is not the case with arrow functions. Calling new on an arrow function results in an exception, as arrow functions are not hardbound functions.

"TypeError: function is not a constructor"

Understanding this distinction is vital for maintaining code clarity and preventing unexpected behavior in edge cases.

The Curly Brace Confusion

One of the persistent frustrations among developers is the assumption that curly braces {} imply a scope. We often associate them with blocks, function bodies, or scopes. However, it's essential to understand that not every set of curly braces denotes a scope.
Consider this example:

const workshop = {
    teacher: "Kyle",
    ask: (question) => {
        console.log(this.teacher, question} 
    },
};

At first glance, it appears that this function is enclosed in a scope. Still, this is not the case. These curly braces merely define the function body; they don't create a scope. Arrow functions don't introduce a new scope like regular functions do.

The Parent Lexical Scope

One common misconception is that arrow functions should inherit the scope in which they are defined. For example, you might expect an arrow function defined within an object to capture that object as its this context. However, this isn't the case.

Arrow functions are not context-aware; they don't possess their own this. Instead, they resolve this lexically, which means they inherit the this from their parent lexical scope. In the global scope, this would typically be the global object.

For example, in the workshop object:

workshop.ask("What happened to 'this'?")
// undefined What happened to 'this'?

The this inside the arrow function does not point to the workshop object but inherits the this from the global scope. So, it logs undefined.

The Right Tool for Lexical this Behavior

Arrow functions are not a one-size-fits-all solution; they are the right tool for maintaining the this context from their parent scope. For instance, when you need to pass a function as a callback to methods like setTimeout, using an arrow function ensures that this remains consistent with the context in which it's defined.
Let's consider a scenario:

workshop.ask.call(workshop, "Still no 'this'");
// undefined Still no 'this'

Here, we explicitly use call to set the this context to the workshop object. However, the arrow function still resolves this lexically, ignoring the provided context. It logs undefined.

Conclusion

The key takeaway here is that arrow functions are not a one-size-fits-all solution. While they excel in certain situations, such as when you require lexical this behaviour, they may not be the best choice for every use case. It's crucial to understand their behaviour and limitations fully. By doing so, you can wield arrow functions effectively, leveraging their strengths while avoiding their potential pitfalls. Ultimately, mastering this powerful feature will help you become a more proficient and versatile JavaScript developer.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 8)? Binding

Sam Abaasi — Thu, 26 Oct 2023 10:24:02 +0000

In JavaScript, the this keyword is a powerful, yet sometimes perplexing, element. Understanding how it behaves is crucial for writing effective and maintainable code. We will discuss four essential ways to invoke a function and how each method affects the binding of this. We will explore these methods, understand their implications, and provide code examples.

Function Invocation and the "this" Keyword
Implicit Binding
Explicit Binding with .call and .apply
The Challenge of Losing this Binding
Hard Binding
Striking a Balance
The new Keyword
Default Binding
Binding Precedence
Conclusion
Sources

Function Invocation and the "this" Keyword

When you invoke a function in JavaScript, the behavior of the this keyword depends on the context in which the function is called. Let's explore the four primary methods of function invocation.

1. Implicit Binding

Implicit binding is one of the most common and intuitive ways to handle the this keyword. It relies on the call site, which is the object used to invoke a function.

const workshop = {
    topic: "JavaScript",
    ask: function () {
        console.log(`Welcome to the ${this.topic} workshop!`);
    },
};

workshop.ask(); // Outputs: Welcome to the JavaScript workshop!

In this example, the this keyword within the ask function refers to the workshop object. Implicit binding associates this with the object that triggers the function.

Implicit binding is a powerful mechanism for sharing behavior among different contexts. You can define a function once and use it across multiple objects, allowing flexibility and code reuse.

2. Explicit Binding with .call and .apply

Explicit binding provides control over the this context of a function using the .call and .apply methods. These methods take the desired this context as their first argument.

const workshop1 = { topic: "JavaScript" };
const workshop2 = { topic: "React" };

function ask() {
    console.log(`Welcome to the ${this.topic} workshop!`);
}

ask.call(workshop1); // Outputs: Welcome to the JavaScript workshop!
ask.call(workshop2); // Outputs: Welcome to the React workshop!

With explicit binding, you explicitly specify the this context, allowing you to share functions across different objects but with precise control.

Implicit Sharing of Behavior

Implicit binding enables developers to share behavior across different contexts by referencing a single function. For example:

const workshop1 = { topic: "JavaScript" };
const workshop2 = { topic: "React" };

function ask() {
    console.log(`Welcome to the ${this.topic} workshop!`);
}

workshop1.ask = ask;
workshop2.ask = ask;

workshop1.ask(); // Outputs: Welcome to the JavaScript workshop!
workshop2.ask(); // Outputs: Welcome to the React workshop!

In this scenario, you share a single ask function between workshop1 and workshop2, invoking it with distinct contexts.

The Challenge of Losing `this` Binding

One challenge in JavaScript is losing the this binding when you pass a function around. Consider the following example:

function delayedAsk() {
    setTimeout(function () {
        console.log(`Welcome to the ${this.topic} workshop!`);
    }, 1000);
}

const workshop = { topic: "JavaScript" };

delayedAsk(); // Outputs: Welcome to undefined workshop!

The this context inside the setTimeout callback function is not bound to the workshop object. Instead, it defaults to the global context, resulting in undefined.

Introducing Hard Binding

To address the issue of losing the this binding, developers often use a technique called "hard binding". This technique ensures that a function's this context remains fixed, no matter how it is called. The .bind method allows you to create a new function with a specific this context:

function delayedAsk() {
    setTimeout(
        function () {
            console.log(`Welcome to the ${this.topic} workshop!`);
        }.bind(this), // Hard binding to the workshop object
        1000
    );
}

const workshop = { topic: "JavaScript" };

delayedAsk(); // Outputs: Welcome to the JavaScript workshop!

By using .bind(this), you force the this context within the setTimeout callback to always reference the workshop object.

This approach provides predictability but sacrifices some of the flexibility inherent in JavaScript.

Hard binding is valuable when you need consistent behaviour across function invocations, but it should be used thoughtfully to balance predictability and flexibility.

Striking a Balance

The choice between flexible and predictable this binding is not accidental; it is intentional. Implicit binding offers flexibility, allowing you to share behavior among different contexts. However, there are scenarios where predictability is essential. The key is to strike a balance:

Use implicit or explicit binding when flexibility is required and different contexts are beneficial.
Utilize hard binding when you need predictability, ensuring that the this context remains fixed.
However, overusing hard binding may lead to a less maintainable and rigid codebase. Strive for a balance that aligns with your project's requirements, offering the right mix of flexibility and predictability for your specific use cases.

3. The `new` Keyword

The new keyword is commonly misunderstood as a class instantiation operator. However, it's not inherently tied to classes. Its true role is to invoke a function with specific behaviours. When you use new with a function, it carries out four distinct tasks:

Creating a New Empty Object: new instantly generates a new empty object. This is the object that the function will operate on.
Linking to Another Object: The new keyword connects the newly created object to another object (to the prototype).
Invoking the Function: The function specified after new is called. However, the function is executed with its this keyword bound to the new object, not the linked one. This is a crucial distinction.
Handling Return Values: After executing the function, if it doesn't return its own object explicitly, the new keyword assumes that the function intends to return this.

Deconstructing the new Keyword

The new keyword is deceptively simple, as it essentially hijacks the constructor function to accomplish these four critical tasks. The function's implementation is secondary to the actions carried out by new. Even if you use new with an entirely empty function, it still executes these four tasks. In essence, it's the new keyword that does the heavy lifting, not the function itself.

Example of Using the `new` Keyword

Here's an illustrative example of how the new keyword works with a constructor function:

function Workshop(topic) {
    this.topic = topic;
}

const jsWorkshop = new Workshop("JavaScript");

console.log(jsWorkshop.topic); // Outputs: JavaScript

In this example, the new keyword creates a new object, links it to Workshop, invokes the Workshop function with the this context set to the new object, and implicitly returns the new object.

4. Default Binding

The fourth way to bind this is the fallback, called default binding. If none of the other three methods apply, the this keyword can default to either the global object (in non-strict mode) or undefined (in strict mode).

var teacher = "Kyle";
function ask(question) {
    console.log(this.teacher,question);
}
function askAgain(question) {
    "use strict";
    console.log(this.teacher,question);
}
ask("Whats the non-strict-mode default?");
// Kyle Whats the non-strict-mode default?

askAgain("Whats the strict-mode default?");
// TypeError

In strict mode, the default behaviour is to leave this undefined, which can cause TypeError if you try to access properties on it.

Binding Precedence

In JavaScript, understanding the binding precedence of the this keyword is essential to determine what it references when a function is invoked. Whether you're working with complex call sites or trying to unravel the intricacies of a particular code snippet, knowing the order of precedence for binding rules can be incredibly helpful. Consider this example:

var workshop = {
    teacher: "kyle",
    ask: function ask(question) {
     console.log(this.teacher, question);
    },
};
new (workshop.ask.bind(workshop))("What does this do?");
// undefined What does this do?

A straightforward guide helps establish this order of precedence when determining the value of this in a function. Let's break down these rules step by step:

1. New Keyword
The first rule of precedence asks one simple question: Was the function called with the new keyword? If the answer is yes, the this keyword will point to the newly created object. This rule takes precedence over all others, making the new keyword a powerful way to explicitly define the context for a function.

2. Call or Apply
The second rule comes into play when the function is invoked using call or apply. It's important to note that bind is a sub-rule of this second rule, as it internally relies on apply. When call or apply is used, the context object specified as the first argument becomes the value of this. This rule allows you to directly control the context of a function.

3. Context Object
The third rule considers whether the function is called on a context object, like workshop.ask in the example. If the function is invoked within a specific object, the this keyword will reference that object. This rule provides a simple and intuitive way to manage context within object methods.

4. Default Binding
When none of the previous three rules apply, the fourth and final rule comes into effect. By default, the this keyword references the global object, except in strict mode. In strict mode, it defaults to undefined. This rule serves as a fallback when other binding rules don't match.

Conclusion

Understanding the behaviour of the this keyword and the four ways to invoke functions in JavaScript is fundamental to writing efficient and maintainable code. By choosing the right method for your specific use case, you can harness the full power of JavaScript's dynamic and flexible nature while ensuring predictable behaviour where needed.

Ultimately, JavaScript offers a variety of tools for function invocation and this binding, allowing you to tailor your code to the demands of your projects. The key is to strike the right balance between predictability and flexibility, enabling you to create robust and versatile JavaScript applications.

But let's reset our minds back. The question that we set out to ask is, if I have a this-aware function, how do I know what its this keyword points at? And our strong temptation is, we want to assume that we can just answer that by looking at the function. What we've now seen is that there's no way to look at the function to answer that question. You have to look at the call site. You have to look at how the function's being called. Because every time it gets called, the how of the call controls what the this keyword will point at.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 7)? `this`

Sam Abaasi — Thu, 26 Oct 2023 10:21:19 +0000

The this keyword in JavaScript has long been a source of confusion and frustration for many developers. It often behaves in ways that seem unintuitive, leading to a sense of bewilderment. However, this is an incredibly powerful mechanism that allows for dynamic context switching in your code. To master it, we need to understand how it works in JavaScript, free from preconceived notions based on other programming languages.

Lexical Scope vs. Dynamic Scope
The Pitfall of Comparisons
The Basics: this Represents the Execution Context
Flexibility and Reusability through this
Explicitly Setting the Context
The Four Ways to Invoke Functions
Conceptualizing Different Buildings
Conclusion
Sources

Lexical Scope vs. Dynamic Scope

Before diving into function invocation, it's crucial to understand two fundamental concepts related to JavaScript's scoping: lexical scope and dynamic scope.

Defining Lexical Scope:

Lexical scope, also known as static scope, refers to the idea that scopes are nested within each other. In this model, a compiler, parser, or processor determines all scopes during the compilation phase, well before the code is executed. This means that the structure of scopes and variable access is decided at author time, during the development of the code.

Compile-Time Decisions:
Lexical scope is closely related to compile time. When we talk about lexical scope, it means that decisions about variable access, function nesting, and scope hierarchy are made at compile time. These decisions are not influenced by what happens at runtime during program execution.
Fixed and Predictable Scope:
The variable references in lexical scope are determined during compilation and do not change during runtime. This means that, at compile time, it's known which variables belong to which scopes.
Optimizability:
Lexical scope is highly optimizable because variable access is determined at compile time. There's no need for the runtime environment to continually look up variable references. Even in cases where variables may not be known at compile time, they can be resolved during the initial execution and remain consistent thereafter.

It's important to note that, despite some nuances, JavaScript fundamentally operates with lexical scope.

Dynamic Scope

Dynamic scope, in contrast, allows runtime conditions to affect scope and variable access. While this model is rare in JavaScript, it's more common in languages like Bash scripting. Dynamic scope offers flexibility, but it can be challenging for developers accustomed to lexical scope.

Flexibility of Dynamic Scope: Dynamic scope allows a function to have different variable resolutions when called from different places. This flexibility can be seen as both powerful and potentially chaotic. While it may seem unfamiliar to developers accustomed to lexical scope, it offers the potential for extensive code reuse.

In JavaScript, you can achieve a level of flexibility similar to dynamic scope using various this binding techniques, as we'll see shortly.

They are simply different models for scoping. Lexical scope is fixed and predictable, determined at author time during compilation, while dynamic scope is runtime-dependent and flexible.

The Pitfall of Comparisons

One common mistake is trying to relate JavaScript's this to the behavior of this in other languages. This can lead to confusion and hinder your ability to understand and utilize JavaScript effectively. It's essential to approach this as a unique JavaScript feature.

The Basics: `this` Represents the Execution Context

The this keyword in JavaScript represents the execution context for a function. Unlike many other languages where this refers to the context of the function's definition, in JavaScript, it's all about how the function is called. It's not determined by where a function is defined but by how it's called This means that this is dynamic and is determined by the context of the function call.

Here's a simple example to illustrate this point:

function sayHello() {
    console.log(`Hello, ${this.name}!`);
}

const person1 = { name: "Alice", sayHello };
const person2 = { name: "Bob", sayHello };

person1.sayHello(); // Outputs: Hello, Alice!
person2.sayHello(); // Outputs: Hello, Bob!

In this example, the sayHello function's this context dynamically changes based on the object from which it is called.

Flexibility and Reusability through `this`

JavaScript's this behavior provides a level of flexibility and reusability in your code that might seem counterintuitive at first. By changing the context of a function when invoking it, you can reuse the same function with different objects or settings.

For instance:

const teacher1 = { name: "Alice" };
const teacher2 = { name: "Bob" };

function introduce() {
    console.log(`I am ${this.name}, your teacher.`);
}

introduce.call(teacher1); // Outputs: I am Alice, your teacher.
introduce.call(teacher2); // Outputs: I am Bob, your teacher.

The call method allows you to alter the context in which the introduce function operates. This dynamic flexibility can be incredibly powerful in real-world JavaScript applications.

Explicitly Setting the Context

In JavaScript, you can explicitly set the context in which a function operates using methods like call, apply, and bind. Each of these methods allows you to change the this context for a given function.

Consider these examples:

const person = { name: "Alice" };

function greet(greeting) {
    console.log(`${greeting}, ${this.name}!`);
}

greet.call(person, "Hello"); // Outputs: Hello, Alice!
greet.apply(person, ["Hi"]);  // Outputs: Hi, Alice!

const greetToAlice = greet.bind(person);
greetToAlice("Hey");  // Outputs: Hey, Alice!

call and apply are used for immediate function invocation, and you can pass arguments directly.
bind creates a new function with the specified context, which can be invoked later.

The Four Ways to Invoke Functions

In JavaScript, there are four primary ways to invoke functions, each influencing how the this keyword behaves:

Function Invocation: Invoking a function as someFunction() uses the global context.
Method Invocation: Invoking a method as object.someMethod() sets this to the object.
Constructor Invocation: Using new SomeConstructor() assigns this to the new instance created by the constructor.
Indirect Invocation: Employing someFunction.call(context, args) specifies the context explicitly.

Conceptualizing Different Buildings

A useful metaphor for understanding this in JavaScript is to think of it as deciding which building to enter. Just as you'd ask which building contains the desired office, you must identify the specific context to determine how this will behave.

conclusion

this in JavaScript is a dynamic and powerful concept, designed to enable flexibility and reusability in your code. While it can be a source of confusion, a deeper understanding of how it works and some practical experience with different function invocations will empower you to harness its capabilities effectively. Shedding preconceived notions about this from other programming languages is the first step towards mastering it in the world of JavaScript.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 6)? Module

Sam Abaasi — Thu, 26 Oct 2023 10:19:43 +0000

The module pattern is a versatile and powerful tool in JavaScript for organizing and structuring your code. At its core, it allows you to create self-contained units called modules, which bundle related data and functions. These modules are fundamental to writing clean, maintainable, and secure code.

Lexical Scope and Closure
The Namespace Pattern Explained
The Namespace Pattern's Shortcomings
What is Encapsulation?
Encapsulation in the Module Pattern
Classic/Revealing Module Pattern
IIFE
The Relationship with Encapsulation
Encapsulation and Closure
A Module's Purpose
Factory Functions for Versatile Modules
The Significance of the Module Pattern: A Modern Necessity
Conclusion
Sources

Lexical Scope and Closure

Before we dive into modules, it's crucial to understand two foundational concepts: lexical scope and closure. Lexical scope deals with how variable names are resolved in nested functions, and closure is the mechanism that allows inner functions to capture and maintain closed-over variables from their containing scope. Here's a detailed example:

function outer() {
  const outerVar = 'I am from the outer function';

  function inner() {
    console.log(outerVar); // Accessing outerVar due to closure
  }

  return inner;
}

const innerFn = outer();
innerFn(); // Outputs: "I am from the outer function"

In this example, the inner function inner can still access outerVar even after outer has completed execution, thanks to closure.

The Namespace Pattern Explained

In the Namespace Pattern, developers collect functions, variables, and objects within an object, often with a specific name relevant to the domain of the code. For example, in a web application, you might use a namespace like MyApp to group various functionalities related to your application.

Here's a basic example of the Namespace Pattern:

var MyApp = {
  utils: {
    formatDate: function(date) {
      // Format the date
    },
    // More utility functions
  },
  modules: {
    // Various modules
  }
};

In this example, MyApp is a namespace that encapsulates both utility functions and application modules.

The Namespace Pattern's Shortcomings

While the Namespace Pattern is effective in preventing global scope pollution, it lacks several characteristics that define a true module:

Why the Namespace Pattern Is Not a Module
The primary reason the Namespace Pattern is not considered a module is that it fails to achieve the level of encapsulation and data hiding that modules provide. Modules are designed to offer a clear distinction between public and private components, which the Namespace Pattern lacks.

Lack of Encapsulation:
In the Namespace Pattern, there is no clear distinction between public and private components. Everything placed within the namespace is accessible, which makes it challenging to achieve proper encapsulation. In a true module, you can hide certain parts of the code, allowing only specific functions and variables to be exposed.
No Data Hiding:
Modules emphasize data hiding, meaning certain data is hidden from the outside world. The Namespace Pattern doesn't inherently provide this level of data protection, as everything within the namespace is exposed.
Limited Control Over Visibility:
In a true module, you have explicit control over what parts of your code are publicly accessible and what remains private. The Namespace Pattern lacks the concept of private and public members.
Risk of Interference: Without proper encapsulation, different parts of the code may inadvertently interfere with each other, leading to unexpected side effects. Modules aim to isolate different sections of your application to minimize interference.
Limited Reusability:
The Namespace Pattern does not inherently promote reusability of code since there is no strict isolation of code components. In a module, you can easily reuse the same module in different parts of your application.

What is Encapsulation?

Encapsulation is the practice of bundling data (variables) and the methods (functions) that operate on that data into a single unit. This unit is typically referred to as an object in object-oriented programming (OOP) or a module in JavaScript. Encapsulation involves two fundamental principles:

Data Hiding: Encapsulation allows you to hide the internal details of an object or module from the external world. It restricts direct access to the object's internal state.
Public and Private Components: Encapsulation distinguishes between what is public and what is private. Public components are accessible from the outside, whereas private components are hidden and can only be accessed from within the object or module.

Encapsulation in the Module Pattern

In the module pattern, encapsulation is a core concept. It enables you to structure your code in a way that provides controlled access to your data and functions. Here's how encapsulation is achieved in the module pattern:

Public Interface: You define a public interface, which consists of functions and variables that you want to expose to the outside world. These are the parts of your module that other parts of your code can interact with.
Private Members: Within the module, you can have variables and functions that are not part of the public interface. These are considered private members, and they are only accessible from within the module itself.
Closure: Closure is the mechanism through which private members are encapsulated. When you create an inner function inside the module, it has access to the module's scope and can capture and preserve private variables. This means that even after the outer module function has executed, the inner functions maintain access to the private data.

Let's illustrate encapsulation in action with a simple example:

function workshopModule() {
  const teacher = 'Kyle Simpson';
  let participants = 0; // Private variable

  function addParticipant() { // Private function
    participants++;
  }

  function getParticipantCount() {
    return participants;
  }

  return {
    addParticipant, // Public function
    getParticipantCount // Public function
  };
}

const workshop = workshopModule();
workshop.addParticipant();
console.log(workshop.getParticipantCount()); // Outputs: 1
console.log(workshop.participants); // Outputs: undefined

In this example, teacher, participants, and addParticipant are encapsulated within the module. addParticipant and getParticipantCount are part of the public interface and can be accessed from outside the module, while teacher and participants remain hidden.

Classic/Revealing Module Pattern

The Classic or Revealing Module Pattern is a fundamental technique for creating modules in JavaScript. It builds on the concepts of encapsulation and closure. The pattern allows you to structure your code in a way that exposes only the necessary functions and variables while keeping others hidden. Here's an example:

var MyModule = (function() {
  var privateVar = 'I am private';

  function privateFunction() {
    console.log('This is a private function.');
  }

  function publicFunction() {
    console.log('This is a public function.');
  }

  // Revealing module pattern
  return {
    publicFunction: publicFunction
  };
})();

MyModule.publicFunction(); // Accessing a public function
MyModule.privateVar; // This is undefined as privateVar is hidden
MyModule.privateFunction(); // This will result in an error

In this pattern, an IIFE is used to create a private scope where you can define both private and public members. The public members are explicitly returned, exposing only the desired functionality to the outside world.

IIFE

An IIFE, or Immediately-Invoked Function Expression, is a JavaScript function that is executed as soon as it is defined. It's commonly used in the module pattern to create a private scope for encapsulating variables and functions. Here's an example:

(function() {
  var data = 'I am private';
  console.log(data);
})();

In this example, the function is invoked immediately after its declaration, and it can be used to create a private environment for encapsulating data.

The Relationship with Encapsulation:

The driving force behind both the Classic/Revealing Module Pattern and IIFE is encapsulation. Encapsulation involves bundling data and functions into a single unit and distinguishing between what's public and private. This practice not only promotes clean code but also enhances security and data integrity.

Encapsulation and Closure

In the context of modules, encapsulation and closure work together to create self-contained units with private and public members. Encapsulation ensures that data and functions are organized within a module, while closure allows private data to be accessible only within the module, even after the outer module function has executed.

A Module's Purpose

One of the primary purposes of a module is to manage shifting state over time. In many applications, data changes and evolves, and modules provide a structured way to handle these changes. By encapsulating state and behavior within a module, you can track the state and ensure that it changes in a controlled manner.

Consider a module that tracks the state of an online workshop's participants. Through encapsulation, you can hide the internal details and provide functions to add and retrieve participants. The module maintains the state, and the outside world interacts with it through a defined public interface.

Factory Functions for Versatile Modules

Unlike the revealing module pattern or object literals, factory functions can be used to produce multiple instances of a module, each with its own isolated state. This versatility makes factory functions an excellent choice when you need to create multiple modules with distinct data. Here's an example:

function createPersonModule(name, age) {
  // Private variables
  var privateName = name;
  var privateAge = age;

  // Public functions
  function getFullName() {
    return privateName;
  }

  function getAge() {
    return privateAge;
  }

  // Public interface
  return {
    getFullName,
    getAge
  };
}

const person1 = createPersonModule('Alice', 30);
const person2 = createPersonModule('Bob', 25);

console.log(person1.getFullName()); // Outputs: "Alice"
console.log(person2.getFullName()); // Outputs: "Bob"
console.log(person1.getAge()); // Outputs: 30
console.log(person2.getAge()); // Outputs: 25

In this example, the createPersonModule factory function is used to create two distinct person modules, each with its private state. This approach is incredibly versatile when you need to manage multiple instances of a module.

The Significance of the Module Pattern: A Modern Necessity

In modern JavaScript development, the module pattern has become more than just a convenient way to structure code. It has evolved into a necessity for several reasons:

Code Organization: As applications become more complex, organizing code becomes paramount. Modules provide a structured way to group related data and functions together, enhancing code maintainability and readability.

Preventing Global Scope Pollution: The global scope is a shared space where variables can collide and cause conflicts. Modules encapsulate their code, reducing the risk of global scope pollution and naming conflicts.

Reusability: Modules can be reused across different parts of an application or in entirely different projects. This reusability reduces code duplication and accelerates development.

State Management: Modules are excellent for managing state, especially in web applications. They allow you to keep track of application state changes and interactions with user interfaces.

Security: By limiting access to specific variables and functions, modules enhance code security. They prevent unauthorized access and modifications of sensitive data.

Interference Mitigation: Modules minimize interference between different parts of an application. Each module operates within its own scope, reducing the risk of unintended side effects.

Maintenance and Collaboration: In a team environment, modules make code maintenance and collaboration more manageable. Developers can work on individual modules without affecting other parts of the application.

Scalability: As applications grow, modules provide a scalable approach to code management. You can add or update modules without extensive changes to the entire codebase.

Conclusion

In modern JavaScript development, the module pattern has become essential. It enhances code organization, prevents global scope pollution, promotes reusability, and improves state management and security. Modules are invaluable for mitigating interference, simplifying maintenance and collaboration, and ensuring code scalability. Whether you choose the Classic/Revealing Module Pattern, use IIFE, or implement factory functions, understanding encapsulation and closure is vital for mastering JavaScript modules. Incorporate these techniques into your codebase, and you'll be well-equipped to write clean, organized, and maintainable JavaScript code.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 5)? Closure

Sam Abaasi — Wed, 25 Oct 2023 18:11:13 +0000

Closures are a fundamental and powerful concept in JavaScript. They play a crucial role in creating maintainable and efficient code. Understanding closures is essential for every JavaScript developer. In this comprehensive guide, we will delve into the world of closures, from their origins to practical examples and best practices.

Introduction to Closure
Origin of Closures
Definition of Closure
What Closure Is
What Closure Is Not
Examples of Closure in JavaScript
- Private Data with Closure
- Callback Functions
- Timers with Closure
- Looping with Closure
Closed Over Variables
Best Practices for Using Closures
Conclusion
Sources

Introduction to Closure

Imagine you have a function in JavaScript that references variables outside its own scope. These variables may belong to a different function or even the global scope. When you use this function, it retains access to those external variables. This phenomenon is known as a closure. Closures allow you to create self-contained and reusable functions that can encapsulate data and behavior effectively.

Origin of Closures

The concept of closure is not unique to JavaScript. It has its roots in lambda calculus, a mathematical concept predating the creation of programming languages. Closures have been present in functional programming languages like Lisp for decades. However, their widespread adoption in more general-purpose languages, such as JavaScript, is relatively recent.

Definition of Closure

Defining closure from an academic perspective can be complex. Instead, let's focus on an operational definition that explains the practical use of closures in JavaScript:

Closure is when a function is able to remember and access its lexical scope, including the variables outside of itself, even when that function executes in a different scope.

This definition consists of two essential parts:

The ability of a function to access its lexical scope.
The preservation of this access even when the function executes in a different scope. These two components collectively form what we refer to as a closure.

What Closure Is

Closures allow JavaScript developers to create powerful and flexible code. Here are some key attributes of closures:

Encapsulation: Closures enable the encapsulation of data within functions, leading to cleaner and more organized code. Data Privacy: Closures protect variables from being directly accessed and modified from outside the function. This privacy enhances security and avoids unintended interference with data.
Controlled Access: Closures provide controlled access to variables by exposing only the necessary functions, preventing unauthorized changes to the data.
Reusability: Closures can create self-contained modules that are reusable across different parts of your codebase.
Callback Functions: Closures are fundamental in handling callback functions, such as event handlers and asynchronous operations.

What Closure Is Not

To understand closures fully, it's crucial to know what they are not:

Capturing Values: Closures do not capture specific values at a particular moment. Instead, they retain access to variables. This means the value of a variable is dynamic and can change over time.
Duplicates of Variables: Closures do not create copies of variables. They maintain a reference to the same variable, which can be modified directly.
Object-Oriented Encapsulation: While closures offer encapsulation, they do not provide class-based object-oriented encapsulation. JavaScript uses prototypes and classes for that purpose.

Examples of Closure in JavaScript

Let's explore practical examples of how closures are used in JavaScript:

Private Data with Closure

Closures can be used to create private data within objects:

function createPerson(name) {
  const privateName = name;

  return {
    getName: function () {
      return privateName;
    },
    setName: function (newName) {
      privateName = newName; // This would cause an error!
    },
  };
}

const person = createPerson("Alice");
console.log(person.getName()); // Output: "Alice"

In this example, the createPerson function returns an object representing a person. It contains two methods, getName and setName. The privateName variable is not directly accessible from outside the function. The closures within the returned object give us controlled access to the privateName variable while protecting it from direct modification outside the function. Attempting to modify privateName directly from outside the closure would result in an error.

Callback Functions

Closures are frequently used in callback functions, such as event handlers and asynchronous operations. Here's a simple example:

function fetchData(url) {
  fetch(url)
    .then((response) => response.json())
    .then((data) => {
      // Here, the `url` variable is closed over by the arrow functions
      console.log(`Data fetched from ${url}:`, data);
    })
    .catch((error) => {
      console.error(`Error fetching data from ${url}:`, error);
    });
}

fetchData("https://api.example.com/data");

In this case, the arrow functions inside the then and catch methods of the promise close over the url variable. This allows us to access the url variable even though the callback functions are executed in a different context, such as when the fetch operation is complete.

Timers with Closure

A common use case for closure is when you set timers using setTimeout or setInterval. These functions involve callbacks that reference variables outside the function. Closure allows these callbacks to access the variables even when the outer function has finished execution.

function waitASec() {
  const question = "What is closure?";
  setTimeout(function () {
    console.log(question);
  }, 1000);
}

waitASec(); // Outputs: "What is closure?"

Looping with Closure

One classic example where developers often encounter issues related to closure is in loop structures. Consider this example with a for loop:

for (var i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log("i: " + i);
  }, 1000);
}

Surprisingly, this code logs "i: 4" three times. Why? Because there's only one variable i, and the closures preserve access to that single variable, resulting in the value 4.

To create separate variables for each iteration, you can use block-scoped variables with let or rely on JavaScript's automatic variable creation for each iteration (ES6).

Closed Over Variables

Understanding how closures handle variables is crucial. In JavaScript, a closure preserves a reference to the entire scope, not just individual variables. This means that even if you only reference one variable within a closure, the entire scope is retained. As a result, variables that you might not explicitly use can still consume memory. It's important to be aware of this when working with closures to avoid unintended memory leaks.

Best Practices for Using Closures

While closures are a powerful tool, they should be used with care. Here are some best practices for working with closures:

Keep Closures Simple: Avoid creating overly complex closures. They should be easy to understand and maintain.
Mind Memory Usage: Be mindful of memory usage, especially when closures reference large objects. Always release references when they're no longer needed.
Avoid Overuse: Not every function needs to be a closure. Use them when they genuinely offer advantages in terms of data encapsulation and controlled access.
Use Block Scoping: When appropriate, use let and block-scoped variables to avoid issues related to loop closures.

Conclusion

In this guide, we've explored the concept of closure in JavaScript, from its origins to practical applications. Closures empower developers to create self-contained functions, encapsulate data, and build reusable code modules. By understanding closures and their best practices, you can write cleaner, more secure, and more efficient JavaScript code. Closures are a powerful tool in the JavaScript developer's toolbox, and mastering them is essential for becoming a proficient JavaScript developer.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 4)? Hoisting, var, let, const, TDZ

Sam Abaasi — Wed, 25 Oct 2023 18:05:47 +0000

JavaScript, often perceived as an interpreted language due to its runtime execution, is, in fact, a language with a two-step process, including a critical compilation stage. The compilation process comprises tokenization/lexing, parsing, and actual code compilation, making JavaScript more than just a simple scripting language. This compilation stage is essential to understand the concept of hoisting.

The Compilation Stage
The Role of Parsing, AST, and Scope Analysis for Hoisting
How Does Hoisting Fit into This Process?
Hoisting with Variable Declarations
Hoisting with Function Declarations
Variable Declarations and Function Declarations
- Function Declarations
- Variable Declarations
let Doesn't Hoist?
Temporal Dead Zone and TDZ Error
TDZ and const
Difference Between var and let/const Hoisting
Function Expressions
Conclusion
Sources

The Compilation Stage

Before a JavaScript program executes, it goes through a series of phases during the compilation stage:

Tokenization/Lexing:
The engine breaks the source code into chunks called tokens. Tokens are the smallest units of a program, like words in natural language.
Parsing: The engine analyzes the syntax of the token stream to create an abstract syntax tree (AST). The AST represents the grammatical structure of the code and helps the engine understand its meaning.
Compilation: During this phase, the engine translates the AST into executable code, often in the form of bytecode or machine code. This compiled code is optimized for execution.

The Role of Parsing, AST, and Scope Analysis for Hoisting

When a JavaScript program is executed, the first crucial step is the parsing of the source code. Parsing is the process of taking raw JavaScript code and transforming it into an Abstract Syntax Tree (AST). This tree-like structure represents the grammatical and structural elements of the code.

The AST, in combination with scope analysis, plays a pivotal role in the process of hoisting.

Scope analysis involves identifying where in the code certain variables and functions are valid or accessible. It is during this analysis that JavaScript engines determine the boundaries of various scopes in your code.

How Does Hoisting Fit into This Process?

Hoisting is not some mystical mechanism but rather a direct consequence of this parsing and scope analysis. It is essentially the act of re-arranging variable and function declarations and attaching them to the top of their appropriate scopes.

Let's break it down:

Variable Declarations:
When you declare a variable using var, for instance, the JavaScript engine identifies it during the parsing phase. It then hoists this declaration to the top of the current scope, ensuring that the variable can be accessed anywhere within that scope. This means that you can use a variable before it's declared in your code without causing an error.
Function Declarations: Similarly, function declarations are also hoisted. The engine recognizes them during parsing, moves them to the top of the current scope, and assigns a reference to the function. This allows you to call a function before it's formally defined in your code.

By performing this hoisting process based on the information gathered from parsing and scope analysis, JavaScript ensures that variables and functions are accessible where they should be. This is why hoisting is often described as just a matter of re-arranging these declarations to the top of their appropriate scopes.

Hoisting with Variable Declarations

Let's start with variable declarations. Consider this code:

console.log(a); // Outputs: undefined
var a = 5;
console.log(a); // Outputs: 5

The magic happens here! Despite trying to console.log the variable a before it's declared, JavaScript doesn't throw an error. Instead, it hoists the variable declaration to the top of the current scope, making it available but uninitialized. The code is effectively treated as if written like this:

var a; // Declaration is hoisted
console.log(a); // Outputs: undefined
a = 5; // Initialization still happens where you originally defined it
console.log(a); // Outputs: 5

Hoisting with Function Declarations

Now, let's see how function declarations are hoisted:

sayHello(); // Outputs: "Hello, World!"
function sayHello() {
  console.log("Hello, World!");
}

In this case, we're calling the sayHello function before its actual declaration. JavaScript hoists the function declaration to the top of the current scope, making it accessible before its appearance in the code. The code behaves as if it were written like this:

function sayHello() {
  console.log("Hello, World!");
}
sayHello(); // Outputs: "Hello, World!"

This demonstrates how function declarations are hoisted in JavaScript, allowing them to be used before they are formally defined in the code.

Variable Declarations and Function Declarations

To grasp the nuances of hoisting, it's essential to differentiate between variable declarations and function declarations. The behavior differs significantly between these two constructs.

Function Declarations

Function declarations are hoisted entirely, encompassing both the declaration and initialization phases. This means that when a function is declared using the function keyword, it is effectively recognized as a function declaration. As a unique feature, function declarations don't require an assignment operator (=) since the JavaScript engine comprehends that they are meant to create a function. This hoisting behavior of function declarations aligns with the rules set forth by the ECMAScript language standard.

The rationale behind hoisting function declarations in their entirety is grounded in the behavior specified in the ECMAScript standard. In JavaScript, functions are considered "first-class citizens," signifying that they are treated as objects and can be referenced much like any other variable or value.

The Benefits of Function Hoisting:

This full hoisting enables the calling of a function before its formal declaration within the code, fostering flexibility in code organization. It also contributes to more readable code, particularly in situations where functions invoke one another.

This consistency in hoisting function declarations is a fundamental aspect of JavaScript's design and execution model. It ensures reliable and predictable behavior across various JavaScript engines and environments, aligning with the ECMAScript language standard.

Variable Declarations

On the other hand, variable declarations exhibit a contrasting hoisting behavior. While they are indeed hoisted, only the declaration part is elevated to the top of the current scope. The initialization of variables, however, remains at its original position in the code. This variance in hoisting behavior distinguishes variable declarations from function declarations.

`let` Doesn't Hoist?

Contrary to common belief, let does hoist, but it exhibits a distinct behavior compared to var. In the case of var, variables are hoisted to the entire function scope and are initialized to undefined at the start of the function's execution. However, when it comes to let, it does hoist, but it doesn't get initialized during the hoisting phase. Instead, it enters what is known as the Temporal Dead Zone (TDZ).

Temporal Dead Zone and TDZ Error

The Temporal Dead Zone (TDZ) is a state where let and const variables exist but remain uninitialized. If you attempt to access a let variable before it's explicitly initialized in your code, JavaScript will throw a TDZ error. This error is a safeguard to ensure that you don't access variables in an unpredictable or incomplete state.

console.log(a); // Throws a ReferenceError: Cannot access 'a' // before initialization
let a = 5;

TDZ and `const`

The concept of TDZ primarily arose because of the behavior of const declarations. If const variables were allowed to be accessed before they were assigned a value, it would contradict the core principle of const, which promises immutability and a single assigned value throughout a variable's lifetime. To prevent this, the TDZ mechanism was introduced.

Difference Between `var` and `let`/`const` Hoisting

The critical difference in hoisting behavior is that var variables are initialized to undefined during hoisting. This means that you can access them right away, even if their assignment happens later in the code. On the other hand, let and const variables don't receive an initial value during hoisting. They enter the TDZ, and the only way to bring them out of this state is to explicitly initialize them using the let or const keyword within the block scope. This behavior ensures a clear and consistent approach to variable initialization in JavaScript.

The const keyword works similarly to let in terms of block scoping but with one crucial difference: it declares variables that cannot be reassigned after they are initialized. This can be particularly useful when you want to ensure that a variable retains its value within a block.

Function Expressions

In contrast, function expressions do not exhibit the same behavior. They are not hoisted in the same way as function declarations. When a function is defined through an expression (typically by assigning it to a variable), it's a runtime operation, not something handled during the compilation phase. This means that the variable associated with a function expression is indeed hoisted, but the assignment, which gives it a function value, is not hoisted. Therefore, attempting to call a function expression before it is assigned will result in a TypeError.

sayHello(); // Throws a TypeError
var sayHello = function () {
  console.log("Hello, World!");
};

The reason for this TypeError is straightforward: you're trying to execute a variable that, at that point in the code, holds the value undefined. In contrast, with function declarations, the engine has a plan to initialize them to undefined during compilation, which provides a safety net for calling them before their actual declaration.

In essence, hoisting in JavaScript, whether for function declarations or expressions, is about ensuring that functions are available throughout their scope. However, the way they are initialized and made accessible varies between declarations and expressions, leading to differences in behavior and potential errors like TypeError when calling an undefined function expression.

Conclusion

Understanding hoisting in JavaScript is essential for writing reliable and predictable code. Hoisting, facilitated by the parsing and scope analysis process, ensures that variables and functions are accessible where they should be. It plays a crucial role in differentiating between variable and function declarations, the behavior of let and const, and the handling of function expressions. This knowledge empowers developers to write clean, organized, and error-free JavaScript code, embracing the intricate, yet powerful, mechanism of hoisting.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 3)? Function Scope, Block Scope

Sam Abaasi — Wed, 25 Oct 2023 15:44:25 +0000

In the world of JavaScript and programming, understanding scopes is crucial. Scopes, organized by functions, are the building blocks of your code's structure. But what can we do with this knowledge of scopes? Why is it important, and how can it help us solve real-world coding challenges? Let's dive into these questions.

Naming Collision Problem
The Principle of Least Exposure
The Function Approach
IIFE Pattern
A Better Solution: Block Scoping
Understanding Block Scoping
Benefits of Block Scoping
Function Declaration vs Function Expression
Named Function Expression vs Anonymous Function Expression
Conclusion
Sources

Naming Collision Problem

One common challenge in programming is dealing with naming collisions. This occurs when two or more identifiers share the same name within the same scope, potentially leading to ambiguity and conflicts. To mitigate this issue, we can leverage our understanding of scopes.

To illustrate the significance of scopes, consider a simple scenario. You have a variable, and later in your code, you use that variable, expecting it to still hold the same value. Everything seems fine until another developer, well-intentioned but unaware of the variable's usage, inserts some code in between. The result? A naming collision.

var teacher = "Alice";

// ... (some code)

var teacher = "Bob";

In this case, a variable named teacher was unintentionally redeclared in the same scope, causing unexpected behaviour. The problem is not that the variable could be reassigned; it's the naming collision that's the root issue.

The problem with using const in this specific context is that const prevents you from reassigning the variable, but it does not prevent you from declaring a new variable with the same name in the same scope. In other words, const enforces that the variable assigned is not reassigned within its scope, but it doesn't guard against naming collisions within the same scope.Consider the following example:

const teacher = "Alice";

// ... (some code)

const teacher = "Bob"; // Syntax error due to redeclaration

This code will throw a syntax error because you're attempting to redeclare a variable that has been declared with const. In this context, the use of const is causing a problem because you're not allowed to redeclare teacher.

The Principle of Least Exposure

To solve such problems, we turn to the "Principle of Least Exposure" or "Principle of Least Privilege." This principle suggests defaulting to keeping everything private and only exposing what's absolutely necessary. Why is this principle so essential in software engineering?

Preventing Naming Collisions

By reducing the surface area for name collisions, we avoid conflicts that arise when two different entities within the same scope try to use the same semantic name for different purposes. Hiding variables within a scope minimizes the chances of naming collisions.

Preventing Misuse

When something is hidden within a scope or kept private, it prevents accidental or intentional misuse. Exposing variables publicly often leads to unintended use by other developers, even if they're advised not to use them. Hiding variables restricts their access.

Enabling Future Refactoring

Perhaps the most crucial benefit of the principle is its ability to protect against future refactoring issues. When something is exposed publicly, it's almost guaranteed that someone will use it. Consequently, when you want to refactor or change the implementation, you risk breaking the existing code that depends on it. Hiding variables provides the freedom to refactor without worrying about breaking dependent code.

The Function Approach

One way to apply the principle of least exposure is by creating functions to encapsulate variables and prevent naming collisions. For instance:

function anotherTeacherScope() {
    var teacher = "Bob";
    // ...
}

This approach introduces a new scope, reducing the likelihood of naming collisions. However, it comes with a trade-off. While it resolves the collision problem, it introduces a function with a name in that scope, potentially shifting the naming collision issue rather than solving it.

IIFE Pattern

To address this problem more effectively, we need a way to create a scope without introducing a new variable name. This approach should allow us to prevent naming collisions without shifting the problem.

One potential solution involves understanding how the code execution process works. By breaking down code execution into two steps - retrieving a variable's value and executing it - we can create a scope that doesn't pollute the enclosing scope with additional variable names. Consider the following example:

(function () {
    var teacher = "Bob";
    // ...
})();

In this code, we've wrapped our code in a function expression and immediately invoked it. While it may look unconventional, it achieves the desired result. It creates a new scope, isolates the variable, and prevents naming collisions without introducing a new variable name.

Immediately Invoked Function Expressions (IIFE)

Immediately Invoked Function Expressions (IIFE). An IIFE is an anonymous function expression that is defined and executed immediately. It serves as a temporary scope, providing structure and isolation for your code. IIFEs can be named or anonymous.

The key advantage of IIFEs is that they allow you to create a scope without polluting the surrounding scope with names. They are often used to handle naming collision issues and provide clarity to your code.

One common use case is to encapsulate code that should only run once, such as setting up configurations. IIFEs create a temporary context for this code to execute and then disappear.

(function() {
    // Your code here
})();

Passing Values to IIFEs: IIFEs are regular functions, which means you can pass arguments to them. This feature adds flexibility, enabling you to pass values and parameters to your IIFE's scope.

Avoid Anonymous IIFEs: While you can use anonymous IIFEs, it's advisable to give them a name that reflects their purpose. Using meaningful names for your IIFEs improves code readability and debugging. Avoid anonymous function expressions, including IIFEs.

A Better Solution: Block Scoping

When it comes to managing variable scope and preventing naming collisions, JavaScript provides a more robust solution known as block scoping. Unlike traditional variable declarations with var, block scoping using let and const allows developers to create isolated scopes within their code. This approach brings a higher level of precision to the control of variables and is particularly useful in scenarios where you want to confine the scope of variables to specific blocks of code.

Understanding Block Scoping

Block scoping leverages curly braces {} to create discrete, limited scopes for your variables. With let and const, you can declare variables within a block, ensuring they are only accessible and relevant within that specific block.

Consider the following example:

var teacher = "Alice";
{
  let teacher = "Bob";
  console.log(teacher); // Bob
}
console.log(teacher); // Alice

In this example, two separate teacher variables exist—one within the block and one outside of it. The inner teacher variable, declared with let, is confined to the block, ensuring it doesn't interfere with the outer variable.

Benefits of Block Scoping

Block scoping provides a range of benefits:

Granular Control: With block scoping, you can finely control where your variables are accessible. This is invaluable in scenarios where you want to avoid accidental variable interference.
Preventing Naming Collisions: Block-scoped variables eliminate the risk of naming collisions within a function or code section. Each block maintains its own scope, ensuring variables don't clash.
Improved Code Clarity: By using block scoping, you explicitly define where a variable is meant to be used, enhancing the readability and maintainability of your code.
Reduced Bugs: Naming conflicts and unintentional variable reassignments can lead to bugs and unexpected behavior. Block scoping helps you catch such issues at the development stage.

Function Declaration vs Function Expression

JavaScript provides two primary mechanisms for creating functions: function declarations and function expressions. The choice between these two approaches significantly impacts your code's organization and visibility.

Function Declaration:
A function declaration is defined with the function keyword as the first thing in a statement. It adds the function's name to the enclosing scope, making it accessible from anywhere within that scope.
Function Expression:
A function expression is a more versatile construct. It arises when the function keyword is not the first thing in a statement. Instead, it's often associated with variables, operators, or parentheses. If it lacks a name, it becomes an anonymous function expression.

The distinction between these two approaches is pivotal, influencing the scope and accessibility of your functions, ultimately affecting your project's organization and functionality.

function teacher() {}
var myTeacher = function anotherTeacher() {
    console.log(anotherTeacher)
}
console.log(teacher)
// function teacher() {...}
console.log(myTeacher)
// function anotherTeacher() {...}
console.log(anotherTeacher)
// ReferenceError: anotherTeacher is not defined.

function expressions are read-only: you cannot assign it to other value.

var clickHnadler = function () {}
// Anonymous Function Expression
var keyHandler = function myKeyHandler() {
    //…
}
// Named Function Expression

Named Function Expression vs Anonymous Function Expression

The decision to use a named or anonymous function expression depends on your project's requirements and coding style. Consider the benefits of each:

Named Function Expression
- Reliable Self-Reference: Named function expressions provide a reliable self-reference, making them suitable for recursion or self-referential use within the function.
- Event Handling: They are useful for event handlers that may need to unbind themselves.
- Accessing Properties: If you need to access properties on the function object, such as its name, named function expressions are more appropriate.
Anonymous Function Expression
- Conciseness: Anonymous function expressions offer brevity, which can be beneficial for small, simple functions.
- Readability: However, they may sacrifice readability, as developers need to infer the function's purpose solely from its body and context.

To tie these concepts back to scopes, consider how named and anonymous function expressions affect scope management. By choosing one over the other, you can control the visibility and accessibility of your functions, thereby influencing your project's scope organization.

Conclusion:

In the world of JavaScript, mastering scopes is akin to wielding a powerful tool for organized and unambiguous coding. Function declarations, function expressions, and IIFEs provide us with the means to structure our code effectively. The Principle of Least Exposure further reinforces the importance of encapsulating variables and preventing naming collisions. Always opt for named function expressions over anonymous ones, and remember that code should be written not only for machines but also for human developers. While arrow functions offer brevity, they can sometimes sacrifice readability, making it vital to choose the right tool for the job. By applying these concepts, you'll write cleaner, more maintainable code, and make your programming journey smoother.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 2)? The lexical scope mechanism of JavaScript

Sam Abaasi — Wed, 25 Oct 2023 15:41:32 +0000

Understanding lexical scope is essential for mastering JavaScript, as it dictates how variables are accessed and resolved at compile time. This article explores the core principles of lexical scope, delving into the definition, how it shapes variable behavior, and its role in the JavaScript two-pass system. We'll also examine the creation of scopes through functions and blocks and explore key concepts like shadowing, global variables, strict mode, types of errors, undeclared vs. undefined variables, nested scopes, and the role of arguments and parameters in JavaScript functions.

Table of Content

Lexical Scope Definition
JavaScript's Two-Pass System
Organizing Scopes with Functions and Blocks
How JavaScript Creates Scopes
Shadowing
Global Variables and Strict Mode
Types of Errors
Undeclared vs. Undefined
Nested Scopes
Arguments and Parameters in JavaScript
Conclusion
Sources

Lexical Scope Definition

Lexical scope consists of two key components: lexical and scope. Lexical refers to the lexing phase of compilation, which we discussed in a previous article. But what exactly is scope?

Scope is the region where JavaScript searches for and accesses variables.

It answers two essential questions:

Key Questions

Lexical scope helps answer two key questions:

What are we looking for? Lexical scope is primarily about finding identifiers, such as variables or functions.
Where are we looking for them?
Lexical scope defines the location where identifiers are accessible in your code.

In essence, we're primarily searching for identifiers, such as variables and functions, within various scopes in your code. Variables play two roles:

Receiving the assignment of a value Variables in this role act as targets, where values are assigned, like x = 42 or myFunc = function func(arguments) {}.
Retrieving a value from the variable Variables in this role serve as sources, where values are retrieved, like console.log(y) or function calls, such as ask().

During the code's execution, JavaScript engine processes scopes, asking two fundamental questions:

What is the position of this variable within the scope?
To which scope does it belong?

JavaScript's Two-Pass System

Understanding how JavaScript handles lexical scope involves recognizing that JavaScript is a two-pass system:

process the code first: Javascript processing of lexical scopes and putting all of these identifiers, into their correct scope in the parsing stage where it goes through all of our code, produces this abstract syntax tree (AST) and produces a plan. This plan is executable code that is handed off to be executed by the other part of the JavaScript engine (Virtual Machine),
execute it: JavaScript virtual machine, which is embedded inside of the same JavaScript engine. It interprets all that plan and use all that information to execute the code, and one of the things that it interprets is, whenever it enters a scope it creates all the identifiers according to what the plan told it to do and locates memory for them

Organizing Scopes with Functions and Blocks

In JavaScript, lexical scopes are created when the code encounters functions and blocks (curly braces {}).

Functions:
When you declare a function, it creates a new scope. Functions can be nested within other functions, forming a hierarchy of lexical scopes.
Blocks:
Blocks defined by curly braces {} in constructs like if, for, and while statements also introduce new lexical scopes.

How JavaScript Creates Scopes

When JavaScript encounters variable or function declarations, it creates scopes and places those identifiers within the appropriate scope. Consider the following code:

var teacher = 'kyle';

function otherClass() {
    var teacher = "saman";
    console.log("Welcome!")
}

function ask() {
    var question = "why";
    console.log(question)
}

In this code, you can observe how JavaScript creates scopes and assigns identifiers:

Variable teacher is assigned in the global scope.
Function otherClass creates a new scope, and a local variable teacher is assigned in that scope.
The function ask also creates a scope, where the variable question is defined.

In lexically scoped languages like Javascript, all the lexical scopes and identifiers, are determined at compile time not in run time. It is used at run time but determined at compile time, this behaviour allows the engine to be much more effective in optimising because everything is known and it is fixed.

After all scopes are determined during the parsing stage, JavaScript knows the scope of each identifier. This knowledge helps optimize execution since everything is pre-determined at compile time.The decision about scopes are author's time decisions

Shadowing

When you have multiple variables with the same name at different scopes, it is called shadowing. This means the innermost variable with the same name takes precedence when accessing that identifier. For example, if you have a local variable named x inside a function, it shadows an outer variable x.

Global Variables and Strict Mode

JavaScript provides a mechanism for dynamic global variables (auto globals) that are automatically created if you try to assign to a variable that has never been formally declared. This behaviour occurs when the variable is not declared in any accessible scope. However, auto globals are discouraged in favour of explicitly declared variables as they can lead to performance issues.

Strict mode in JavaScript enforces stricter error handling and helps catch potential issues early in development. It's not always enabled by default but is commonly used in modern development tools and transpilers. Inside class and ES6 modules, you don't need to explicitly declare "use strict"; strict mode is assumed.

Types of Errors

JavaScript can throw various types of errors:

TypeError: Occurs when you perform illegal operations with variables, such as attempting to execute undefined or null, access properties on undefined or null, or reassign a const variable.

TypeError happens at runtime.

SyntaxError: Happens when there are syntax errors in your code, such as extra parentheses or curly braces, improper dots, or illegal operations with let or const, like redefining a variable multiple times.

SyntaxError occurs during the compile time.

ReferenceError: This error arises when you try to access a variable that doesn't exist, and JavaScript can't find it. ReferenceError includes situations like accessing undeclared variables or trying to access variables before they are declared.

ReferenceError happens at runtime.

Undeclared vs. Undefined

Understanding the difference between undeclared and undefined is crucial in JavaScript:

Undefined: It signifies that a variable exists but currently has no assigned value. It might have never had a value or previously had a value but doesn't at the moment. It represents an empty state, where the value is missing.
Undeclared: An undeclared variable doesn't exist in any accessible scope. It's essentially unknown in your code, and trying to access it results in a ReferenceError.

Nested Scopes

JavaScript's lexical scopes can be envisioned as nested layers, similar to a multi-story building. JavaScript conducts a sequential search for variables, beginning from the current scope (the first floor) and progressively moving to outer scopes. This process mimics a linear search, akin to using an elevator to traverse floors within a building.

In this conceptual analogy:

The first floor represents the current scope, where a reference is made.
The top floor corresponds to the global scope. The search progresses one floor at a time, ensuring that variables are resolved in a structured and predictable manner. This methodology forms the foundation of JavaScript's lexical scope.

Arguments and Parameters in JavaScript

In JavaScript, functions play a crucial role in processing data and performing tasks. To understand how functions work, it's essential to grasp the concept of arguments and parameters, which are integral to how functions receive and process data.

Parameters: Receiving Data

Parameters are the placeholders or variables defined in a function's declaration. They act as targets for the data you pass to the function when you call it. Parameters specify what kind of data the function expects to work with and provide names for accessing that data within the function's scope.

Here's an example of a function with parameters:

function greet(name) {
  console.log(`Hello, ${name}!`);
}

In this function, name is a parameter. It serves as a target for the data you pass when calling the greet function. For instance, if you call greet("Alice"), the parameter name will take on the value "Alice," and the function will greet Alice.

Arguments: Passing Data

Arguments are the actual data or values you provide when calling a function. These values are assigned to the function's parameters. Arguments are the source of data that the function works with.

Here's how you pass arguments to the greet function:

greet("Bob"); // "Bob" is the argument
greet("Carol"); // "Carol" is the argument

In these examples, "Bob" and "Carol" are the arguments that get assigned to the name parameter within the greet function.

Parameters Create Identifiers

It's important to note that when you declare parameters in a function, they formally create identifiers within the function's scope. These identifiers allow the function to access and work with the data you pass as arguments.

In the greet function example:

function greet(name) {
  console.log(`Hello, ${name}!`);
}

The name parameter is a formal identifier within the function's scope, allowing you to use it to reference the argument you pass when calling the function.

Conclusion

By delving into these fundamental aspects of lexical scope, you'll gain a deeper understanding of JavaScript and how it manages variables, errors, and scope. This knowledge is invaluable for writing efficient, optimized code and solving complex programming challenges.

Sources

Kyle Simpson's "You Don't Know JS"
MDN Web Docs - The Mozilla Developer Network (MDN)

🚀How JavaScript Works (Part 1)? Look At JS Engine

Sam Abaasi — Mon, 16 Oct 2023 08:52:39 +0000

Two Pivotal Phases of a JavaScript Program: Compilation and Execution
From Code to Bytecode (Executable Code)
The Role of Compilers in JavaScript: Translating Human Logic into Machine Instructions
Understanding Compilers
Lexical Analysis (Lexing or Tokenization)
Syntax Parsing (Abstract Syntax Tree - AST)
Bytecode Generation

Introduction:

Have you ever wondered about the magic that transforms your code into the interactive web pages users adore? What truly unfolds behind the scenes when you engage with a web page? Join me on a journey as we unravel JavaScript's secrets, focusing on its powerhouse, the JavaScript engine.

Demystifying the JavaScript Engine for Developers:

Every web interaction owes its magic to the JavaScript engine—a mysterious wizard that interprets and executes code to create dynamic web experiences. In this article, we'll embark on a journey to demystify JavaScript, showing how it transforms your code into captivating web features. As developers, understanding this is key to mastering web development.

Understanding the JavaScript Engine:

Before we venture into the intricacies of JavaScript, let's familiarize ourselves with the star of the show – the JavaScript engine. A JavaScript engine is a formidable piece of software that takes on the formidable task of interpreting and executing JavaScript code. While different web browsers may employ distinct JavaScript engines, they all adhere to common principles and share the same fundamental goals.

Two Pivotal Phases of a JavaScript Program: `Compilation` and `Execution`

As we delve deeper into the inner workings of JavaScript, we encounter two pivotal phases that define the lifecycle of a JavaScript program: compilation and execution. These phases dance in perfect harmony, ensuring that your code runs not only efficiently but also reliably.

From Code to Bytecode (Executable Code):

Our journey into the heart of JavaScript commences with developers crafting lines of code, each intended to perform specific tasks. Yet, as brilliant as human-readable code may be, browsers are mere machines incapable of deciphering the intricacies of our linguistic marvel. Thus, the transformation of JavaScript code into a format that machines can comprehend is essential. This intermediary format is known as bytecode, a compact, lower-level representation of our high-level code.

From Code to Bytecode (Executable Code)

The Role of Compilers in JavaScript: Translating Human Logic into Machine Instructions

To understand the compilation phase of JavaScript comprehensively, it's crucial to grasp the pivotal role played by compilers. A compiler is a fundamental component of JavaScript engines, serving as the bridge that transforms your human-readable code into a form that machines can interpret and execute efficiently.

Understanding Compilers:

At its core, a compiler is a type of software that translates source code written in a high-level programming language (in our case, JavaScript) into a lower-level representation known as bytecode or machine code. This transformation involves several essential steps, collectively known as the compilation process.

1. Lexical Analysis (Lexing or Tokenization):

The compilation process begins with lexical analysis, also referred to as lexing or tokenization. During this phase, the compiler breaks down your JavaScript code into individual tokens. Tokens are the fundamental building blocks of your code and encompass keywords, variables, operators, and other essential elements. This initial step simplifies the code and makes it more manageable for further analysis.

Example:
Consider the following JavaScript code snippet:

function helloWorld() {
  console.log("Hello World!")
}

Lexical analysis breaks it into the following tokens:

[
  { type: 'keyword', value: 'function' },
  { type: 'identifier', value: 'helloWorld' },
  { type: 'punctuation', value: '(' },
  { type: 'punctuation', value: ')' },
  { type: 'punctuation', value: '{' },
  { type: 'identifier', value: 'console' },
  { type: 'punctuation', value: '.' },
  { type: 'identifier', value: 'log' },
  { type: 'punctuation', value: '(' },
  { type: 'string', value: 'Hello World!' },
  { type: 'punctuation', value: ')' },
  { type: 'punctuation', value: '}' }
]

Lexical Analysis (Lexing or Tokenization)

2.Syntax Parsing (Abstract Syntax Tree - AST):

Following lexing, the compiler proceeds to syntax parsing. During this phase, it constructs an Abstract Syntax Tree (AST) based on your code's grammatical structure. The AST serves as a structured representation of your code, capturing the hierarchical relationship between different elements.

Example:
For the code snippet

function helloWorld() {
  console.log("Hello World!")
}

the resulting AST might appear as follows:

FunctionDeclaration
├── id: Identifier (name: "helloWorld")
├── params: []
└── body: BlockStatement
    └── body: 
        └── ExpressionStatement
            └── expression: CallExpression
                ├── callee: MemberExpression
                │   ├── object: Identifier (name: "console")
                │   ├── property: Identifier (name: "log")
                │   └── computed: false
                └── arguments: 
                    └── Literal (value: "Hello World!")

The FunctionDeclaration node signifies the declaration of a function.
- id: Identifier (name: "helloWorld") denotes the function name.
- params: An empty array [] signifies that there are no parameters for this function.
- body: BlockStatement represents the function's body.
- body: BlockStatement represents the block of code inside the function.
  - type: ExpressionStatement signifies an expression statement.
  - expression: CallExpression represents a function call.
    - callee: MemberExpression represents the member access of the console.log function.
    - object: Identifier (name: "console") is the object (console) on which the function is called.
    - property: Identifier (name: "log") is the function being called.
    - computed: false indicates that the property is not computed.
    - arguments: An array containing a single element:
    - Literal (value: "Hello World!") is the argument passed to the console.log function, a string literal with the value "Hello World!".

Syntax Parsing (Abstract Syntax Tree - AST)

Errors Occur During the Parsing Phase:

The parsing phase serves as the stage where errors come into the spotlight. These errors can be categorized into several types:

Syntax Error: The JS engine first parsing the entire program before any of it is executed. Consider this example:

var greeting ="Hello";
console.log(greeting)
greeting = ."Hi";
//SyntaxError: unexpected token '.'

This program produce no output, instead throws a SyntaxError, since SyntaxError happens after well-formed console.log(..) statement, if JS was executing top-down line by line, one would expect the "Hello" message being printed before the SyntaxError being thrown.

Early Errors:Consider this code:

console.log("Howdy");

saySomething("Hello", "Hi");
// Uncaught SyntaxError: Duplicate parameter name
// not allowed in this context
function saySomething(greeting, greeting) {
   "use strict";
   console.log(greeting);
}

The SyntaxError here is thrown before the program is executed because saySomething(..) function have duplicate parameter names and strict-mode opted in it.Have duplicate parameter always been allowed in non strict-mode.
Although the error thrown is not a syntax error in the sense of being malformed strings of tokens (like ."Hi" in previous example), but in strict-mode is nonetheless required by the specification to be thrown as an "early error" before any execution begins.

Hoisting Error:Consider this example:

function saySomething() {
   var greeting ="Hello";
   {
     greeting = "Howdy";
     let greeting = "Hi";
     console.log(greeting);
   }
}
saySomething()
// ReferenceError: cannot access 'greeting' before
// initialization

Here ReferenceError occurs from the line with the statement greeting = "Howdy", whats happening is that the greeting variable for that statement belongs to the declaration on the next line let greeting = "Hi", rather than to the previous var greeting = "Hello" statement.
Because JS engine processed this code in an earlier pass and set up all the scopes and their variable associations, know at which line the error is thrown.

3. Bytecode Generation:

Finally, after the transformation and optimization processes, the compiler generates bytecode. Bytecode is a compact, lower-level representation of your code's logic. It's an intermediary form that strikes a balance between human readability and machine executability. Bytecode is crucial for efficient execution by the JavaScript engine's virtual machine.

Just-In-Time (JIT) Compilation: A Performance Boost

In the world of JavaScript execution, JIT (Just-In-Time) Compilation is a silent hero. It dynamically optimizes your code just before execution, resulting in remarkable performance improvements. While we won't dive deep into JIT compilation in this article, it's worth noting that modern JavaScript engines employ this technique to make your web applications more responsive and efficient.

From Code to Bytecode with JIT

Transitioning to the Next Article: Understanding JavaScript's Scope

With a solid grasp of how compilers translate JavaScript code into bytecode, we're now well-prepared to delve into the exciting world of execution. This is where your code comes to life, interacts with the web page, and responds to user actions. But our journey doesn't end here. In the upcoming articles, we'll continue to explore the fascinating landscape of JavaScript.

In the next article, we'll venture into the realm of "Scope." Scope is a fundamental concept in JavaScript that defines where variables and functions are accessible within your code. Understanding scope is like unlocking a superpower that allows you to control how data is shared and manipulated, leading to more efficient and maintainable code.

Stay tuned for our exploration of JavaScript's scope, where we'll unravel the mysteries of global scope, function scope, block scope, and lexical scope. It's a journey that will empower you to write code that's not only functional but also elegant and organized. Join us on this captivating journey as we dive deeper into the heart of JavaScript's inner workings.

This transition sets the stage for the next article's topic, "Scope." If you have any further adjustments or specific points you'd like to include, please let me know!

If you have any questions or specific points to discuss, please feel free to reach out!

Sources:

Kyle Simpson's "You Don't Know JS: Scope & Closures"
MDN Web Docs - The Mozilla Developer Network (MDN)
Official Documentation of JavaScript Engines - V8 , SpiderMonkey, ChakraCore and others.

The Evolution of React Design Patterns: From HOCs to Hooks and Custom Hooks

Sam Abaasi — Fri, 25 Aug 2023 14:34:41 +0000

"To evolve is to find better ways of doing things." - Dan Abramov

In the early days of React development, developers faced a myriad of challenges. React applications were becoming increasingly complex, and issues related to component reuse, state management, and code maintainability emerged as common adversaries. React's core team, which boasts notable members like Dan Abramov, Sebastian Markbåge, Sophie Alpert, and Andrew Clark, recognized these challenges and set out on a quest to unearth better design patterns. This article takes you on a journey through the evolution of React design patterns, from the birth of High-Order Components (HOCs) to the groundbreaking era of React Hooks and the rise of Custom Hooks.

Chapter 1: High-Order Component (HOC) Pattern

Problems That Necessitated HOCs

In the early React days, component reuse was a formidable hurdle. Managing shared state was a labyrinthine task, and codebases were evolving into tangled webs of complexity. The React team, including the influential Dan Abramov, acknowledged these problems and embarked on a quest to find solutions.

Dan Abramov emphasized the issues with mixing data-fetching and rendering logic within components in his seminal article: "Extracting your components’ data dependencies lets you reuse presentational components with different data sources." This was a pivotal moment in the evolution of React patterns.

Enter High-Order Components (HOCs)

To address the issues at hand, the concept of High-Order Components (HOCs) was born. HOCs allowed developers to wrap components, thereby enhancing their functionality and reusability. With HOCs, shared logic and behavior could be abstracted and applied across the application.

Here's a real-world example of a simple HOC that adds authentication logic to a component:

import React, { Component } from 'react';

const withAuthentication = (WrappedComponent) => {
  class WithAuthentication extends Component {
    constructor(props) {
      super(props);
      this.state = {
        isAuthenticated: false,
      };
    }

    componentDidMount() {
      // Check authentication logic here
      const isAuthenticated = // Your authentication check logic
      this.setState({ isAuthenticated });
    }

    render() {
      if (!this.state.isAuthenticated) {
        return <div>Authentication failed. Please log in.</div>;
      }
      return <WrappedComponent {...this.props} />;
    }
  }

  return WithAuthentication;
};

export default withAuthentication;

Pros of HOCs

HOCs bestowed React development with several advantages. They facilitated code reuse by enabling the wrapping of components with specific behaviors. For example, a withAuthentication HOC could be used to protect routes requiring authentication. Developers reveled in the flexibility and composability that HOCs offered.

Dan Abramov: "Higher-Order Components (HOCs) allow you to reuse component logic. This is achieved by wrapping a component in a function that returns a new component with the desired behavior."

Cons and Weaknesses of HOCs

However, HOCs were not without their set of challenges. Wrapping components with HOCs led to an abundance of wrapper components, resulting in a complex hierarchy. Debugging and comprehending component structures became increasingly daunting, and the term "wrapper hell" found its place in React discourse.

Dan Abramov: "HOCs don’t solve every problem. They can make your code more complex by introducing unnecessary layers of abstraction, and they can be a little harder to understand."

Chapter 2: Presentation and Container Pattern

Transition to Presentation and Container

As the React community grappled with the limitations of HOCs, a new pattern emerged: the Presentation and Container pattern. This pattern sought to address the issues brought about by HOCs while preserving their strengths. It delineated components into two distinct categories: presentation components responsible for rendering, and container components responsible for data logic.

Here's an example of a presentation component:

import React from 'react';

const PresentationComponent = ({ data }) => (
  <div>
    <h1>Data Presentation</h1>
    <p>{data}</p>
  </div>
);

export default PresentationComponent;

And a container component that manages the state and logic:

import React, { Component } from 'react';

class ContainerComponent extends Component {
  constructor(props) {
    super(props);
    this.state = {
      data: '',
    };
  }

  componentDidMount() {
    // Fetch data and update state here
    const data = // Your data fetching logic
    this.setState({ data });
  }

  render() {
    return <PresentationComponent data={this.state.data} />;
  }
}

export default ContainerComponent;

Pros of Presentation and Container

The Presentation and Container pattern introduced clarity into React codebases. Presentation components evolved into pure, stateless components dedicated solely to rendering. Container components assumed the role of managing data logic and maintaining component state. This segregation simplified testing and bolstered code maintainability.

Sebastian Markbåge: "The goal of the presentation and container pattern is to improve reusability, testability, and the overall organization of your components."

Cons and Weaknesses of Presentation and Container

Nonetheless, this pattern was not a panacea. Developers frequently found themselves creating multiple container components for a single presentation component, resulting in an abundance of files and an escalation of complexity. The pattern, while an improvement, had its complexities and challenges to contend with.

Sophie Alpert: "Sometimes you may need to write a container component even when you don't feel like it's reusing any logic, and that's okay. It's not about how much logic you reuse, but how much you can understand at a glance."

Chapter 3: The Emergence of React Hooks

Introduction to React Hooks

The React landscape experienced a monumental shift with the advent of React Hooks. Hooks were envisioned as a remedy for the challenges posed by both HOCs and the Presentation and Container pattern. They empowered functional components to manage state and side effects without the need for class components.

Here's an example of a functional component using the useState and useEffect hooks:

import React, { useState, useEffect } from 'react';

const HooksComponent = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
};

export default HooksComponent;

Pros of React Hooks

React Hooks ushered in a new era of simplicity and reusability. They enabled functional components to manage local state, side effects, and context with remarkable ease. The concise syntax and elimination of class components resonated with developers, resulting in cleaner and more readable code.

Dan Abramov: "React Hooks aim to solve the problems of render props and higher-order components in a way that feels more natural and comes with fewer trade-offs."

Cons and Weaknesses of React Hooks

Despite their widespread acclaim, React Hooks were not entirely devoid of challenges. Adapting existing class components to functional components with hooks required effort and consideration. Additionally, certain lifecycle methods, such as getSnapshotBeforeUpdate, remained exclusive to class components.

Sophie Alpert: "Hooks don't cover all use cases yet, and they might never cover all use cases. That's why we're not deprecating classes. The goal is to provide alternatives, not to force people to change their habits."

Chapter 4: The Ascendance of Custom Hooks

Custom Hooks as a Pattern

The React community's insatiable appetite for innovation paved the way for the Custom Hooks pattern. Custom Hooks represented a paradigm shift in React design patterns, enabling developers to encapsulate and share logic across components with unparalleled simplicity.

Here's an example of a custom hook that manages a toggle state:

import { useState } from 'react';

const useToggle = (initialValue = false) => {
  const [value, setValue] = useState(initialValue);

  const toggle = () => {
    setValue(!value);
  };

  return [value, toggle];
};

export default useToggle;

Pros of Custom Hooks

Custom Hooks provided React developers with the ultimate tool for code organization and reuse. They unlocked the potential for logic abstraction and distribution, transforming complex components into concise compositions of custom hooks. The newfound modularity elevated React applications to new heights of maintainability.

Andrew Clark: "Custom Hooks let you extract component logic into reusable functions. This is especially useful for sharing behavior across components, such as form handling or animations."

Cons and Weaknesses of Custom Hooks

While Custom Hooks significantly enriched the React ecosystem, they were not a silver bullet. The proliferation of custom hooks across codebases warranted thoughtful naming and documentation. Developers needed to ensure that the purpose and usage of custom hooks were well-understood to prevent confusion.

Andrew Clark: "Custom Hooks can be a double-edged sword. When used appropriately, they can make your code more organized and reusable. However, misuse or excessive use can lead to confusion and unnecessary complexity."

Chapter 5: The Ongoing Evolution

As the React ecosystem matures, the landscape of design patterns and best practices continues to evolve. Let's take a closer look at how these patterns have adapted and explore real-world examples that demonstrate their ongoing evolution.

1. High-Order Component (HOC) Pattern

Evolution: Render Props

The HOC pattern, once a cornerstone of React development, has seen a shift toward more flexible patterns like Render Props. While HOCs remain relevant, Render Props offer a more intuitive way to share code between components.

Example:

Consider a common scenario where you need to fetch and display data. Instead of wrapping components with an HOC, you can use a Render Props component:

class DataFetcher extends React.Component {
  state = {
    data: null,
  };

  componentDidMount() {
    // Fetch data and update the state
  }

  render() {
    return this.props.render(this.state.data);
  }
}

<DataFetcher render={(data) => <DisplayData data={data} />} />

Render Props provide greater component composability and reduce the nesting of higher-order components.

2. Presentation and Container Pattern

Evolution: Component Composition

While the Presentation and Container pattern emphasized separation of concerns, modern React development promotes component composition. Composing smaller, reusable components has become a prevailing practice.

Example:

Instead of creating a separate Container component for data fetching, you can compose your UI from smaller components:

function WeatherDisplay({ city }) {
  const { data, error, loading } = useWeatherData(city);

  if (loading) {
    return <LoadingSpinner />;
  }

  if (error) {
    return <ErrorMessage error={error} />;
  }

  return <WeatherInfo data={data} />;
}

This approach enhances reusability and simplifies component hierarchies.

3. React Hooks

Evolution: Concurrent Mode

React Hooks represent a pivotal advancement, but the evolution doesn't stop there. Concurrent Mode, an experimental React feature, is set to further improve the user experience by allowing React to work on multiple tasks simultaneously.

Example:

Suppose you're building a resource-intensive application. Concurrent Mode can help prioritize rendering updates for critical components, ensuring a smoother user experience.

function ResourceIntensiveComponent() {
  // Resource-intensive rendering logic
}

export default React.memo(ResourceIntensiveComponent, (prevProps, nextProps) => {
  // Implement custom comparison logic
  return prevProps.data === nextProps.data;
});

By implementing custom comparison logic, Concurrent Mode can focus resources where they're needed most.

4. Custom Hooks

Evolution: External Libraries and the Community

Custom Hooks have empowered developers to create their own libraries and share them with the community. As React's ecosystem expands, external libraries offer even more powerful and specialized solutions.

Example:

Imagine you're working on a project that requires complex state management. Instead of reinventing the wheel, you can leverage external libraries like Redux or Mobx, which provide robust state management solutions.

import { useSelector, useDispatch } from 'react-redux';

function Counter() {
  const count = useSelector((state) => state.counter);
  const dispatch = useDispatch();

  return (
    <div>
      <span>Count: {count}</span>
      <button onClick={() => dispatch({ type: 'INCREMENT' })}>Increment</button>
      <button onClick={() => dispatch({ type: 'DECREMENT' })}>Decrement</button>
    </div>
  );
}

By embracing external libraries and community-driven solutions, you can harness the collective expertise of the React community.

Conclusion

The journey through React design patterns serves as a testament to the dynamic nature of web development. From the early struggles of component reuse to the dawn of Hooks, React's evolution has been nothing short of extraordinary. As you navigate your React projects, remember the rich history of these patterns, and wield them to craft maintainable, efficient, and scalable applications.

Diverse Insights from React Team

For deeper insights into the React team's perspectives, delve into their articles and opinions:

Dan Abramov on Presentational and Container Components
Sebastian Markbåge on React Component Patterns
Sophie Alpert on Component Patterns and Composition
Andrew Clark on the Adoption and Impact of Hooks
These resources offer invaluable insights into the motivations and philosophies that shaped React's design patterns.

Forem: Sam Abaasi

Avoiding Unsafe Calls in JavaScript and React Projects with ESLint

Avoiding Unsafe Calls in JavaScript and React Projects with ESLint

Common Issues with Unsafe Calls

1. Accessing Properties on undefined or null 🌟🔍✨

Problem:

Solution:

2. Calling Methods on undefined or null ✋📉📋

Problem:

Solution:

3. Invoking Undefined Functions ⚙️⚠️🚫

Problem:

Solution:

4. Destructuring Undefined or Null Objects 📦❌🔓

Problem:

Solution:

5. Accessing Non-Existent Array Elements 🚫📋📊

Problem:

Solution:

6. Invalid Array/Function Usage 🛑📝

Problem:

Solution:

7. Insufficient Conditional Checks 💡🔒

Problem:

Solution:

Using ESLint to Avoid Unsafe Calls 🚀🔒✅

ESLint Configuration 📜💻🛡️

Explanation of Rules 💡⚙️🌐

Installing Required Dependencies 📦🔧🔍

Integrating ESLint with VSCode 🖥️🚦🌈

1. Install the ESLint Extension:

2. Enable Auto-Fixing:

3. Run ESLint:

Conclusion 🌟🚀📘

🚀How JavaScript Works (Part 10)? Class

Table of Contents

The Class Syntax

Extending Classes

Relative Polymorphism

Beyond Syntactic Sugar: A Closer Look

Preserving this

Understanding Prototype

The Challenge of Maintaining this Context

The Concept of Auto-Binding

The Problem with Auto-Binding Methods

The Hacky Solution

Violating JavaScript's DNA

The Danger of Permanent Hacks

Best Practices: Embracing the Full Power of Classes

Conclusion

Sources

🚀How JavaScript Works (Part 9)? Arrow functions and lexical this

Table of Contents

The Anonymous Nature of Arrow Functions

The Inferred Purpose

The Power of Descriptive Function Names

The Readability Factor

Arrow Functions in the Context of this

The Essence of Lexical this

Arrow Functions and the new Keyword

The Curly Brace Confusion

The Parent Lexical Scope

The Right Tool for Lexical this Behavior

Conclusion

Sources

🚀How JavaScript Works (Part 8)? Binding

Table of Contents

Function Invocation and the "this" Keyword

1. Implicit Binding

2. Explicit Binding with .call and .apply

Implicit Sharing of Behavior

The Challenge of Losing this Binding

Introducing Hard Binding

Striking a Balance

3. The new Keyword

Deconstructing the new Keyword

Example of Using the new Keyword

4. Default Binding

Binding Precedence

Conclusion

1. Accessing Properties on `undefined` or `null` 🌟🔍✨

2. Calling Methods on `undefined` or `null` ✋📉📋

Preserving `this`

The Challenge of Losing `this` Binding

3. The `new` Keyword

Example of Using the `new` Keyword

The Basics: `this` Represents the Execution Context

Flexibility and Reusability through `this`

`let` Doesn't Hoist?

TDZ and `const`

Difference Between `var` and `let`/`const` Hoisting