开发人员常犯的 JavaScript 错误

您是否曾经遇到过这样的情况：您正在使用 JavaScript 创建功能性 Web 应用程序，突然间，您的完美构建变成了嵌入粗红线（错误）中的噩梦？沮丧开始出现，你会感到担忧，质疑自己的技能并问自己，“出了什么问题？”

有趣的是，在大多数情况下，代码中断和错误的原因并不是一些复杂的错误，而是隐藏在代码基础中的常见错误。在这种情况下，本指南将成为您编码之旅的指南针。

在本文中，您将学习如何克服这些常见错误。本指南将提供引人入胜的解释和实用的解决方案，您可以在其中看到错误以及如何修复它们。

话不多说，让我们开始吧。

误用 let、var 和 const - 变量作用域

在 JavaScript 中，您可以使用 let、var 或 const 等关键字声明变量。虽然开发人员通常将 var 和 let 视为可互换的，因为它们具有共享的可变性特性（允许使用它们声明的变量被更改或变异），但它们的作用域存在关键区别。必须认识到这些关键字在定义变量范围的方式上存在显着差异。

var 与 let 和 const 有何不同？

JavaScript 将作用域分为全局作用域、函数作用域和块作用域。在本节中，您只需要关注两种类型的作用域：函数和块。

函数作用域：函数内声明的变量只能在该函数内访问，而不能在函数外部访问。该技术封装并防止代码其他部分的意外修改。

块作用域：在 ES6 (ECMAScript 2015) 中引入，块作用域允许您在大括号定义的特定代码块内使用 let 和 const 关键字声明变量，例如 if 语句、循环和箭头函数。这提供了对变量可访问性的更精确的控制，并有助于防止不必要的副作用。

考虑到块作用域的定义，您可能已经注意到缺少 var 关键字。这是一个疏忽吗？一点也不！使用 var 关键字定义的变量是函数作用域的，而使用 let 或 const 声明的变量是块作用域的。以下代码片段将进一步阐明这些概念。

我们首先将函数作用域的定义翻译成代码：

function testVar() {
  var test = "new variable";
}
console.log(test);
// This will return an error: Uncaught ReferenceError: test is not defined.

上面的代码确认使用 var 关键字声明的变量是函数作用域的。当您尝试在定义该变量的函数之外使用 console.log() 语句访问测试变量时，您会收到错误 - “Uncaught ReferenceError：测试未定义。”

在这种情况下，变量的作用域仅限于定义它并随后被销毁的函数。因此，在函数外部，console.log() 语句会导致错误，因为变量在销毁时会从内存堆栈中删除。

但是，与之前的尝试不同，在定义函数中使用 console.log() 语句访问测试变量可以检索变量的值，而不会遇到引用错误。

function testVar() {
  var test = "new variable";
  console.log(test); // This returns - new variable
}

testVar();

下面的代码将帮助您了解这些变量如何根据其作用域类型工作。

function variableScopes() {
  // testing var scope
  var varTest = 1;
  if (true) {
    var varTest = 2;
    console.log("Inside this if block, var yields this:", varTest);
  }
  console.log("Outside the if block, var yields this:", varTest);

  // testing let scope
  let letTest = 1;
  if (true) {
    let letTest = 2;
    console.log("Inside this if block, let yields this:", letTest);
  }
  console.log("Outside the if block, let yields this:", letTest);

  // testing const scope
  const constTest = 1;
  if (true) {
    const constTest = 2;
    console.log("Inside this if block, const yields this:", constTest);
  }
  console.log("Outside the if block, const yields this:", constTest);
}

variableScopes();
// The code result:
// Inside this if block, var yields this: 2
// Outside the if block, var yields this: 2
// Inside this if block, let yields this: 2
// Outside the if block, let yields this: 1
// Inside this if block, const yields this: 2
// Outside the if block, const yields this: 1

从上面的代码中扣除：

• var：var 关键字是函数作用域的，这意味着用 var 声明的变量可以在整个函数中访问。提供的代码在 if 语句内部和外部声明变量 varTest 两次。然而，由于 var 的函数作用域，该变量本质上是在同一作用域内重新声明的，从而导致意外的行为。因此，当 if 块内修改 varTest 的值时，它会影响块外声明的变量，导致两个 console.log 语句都显示值 2。

• let：与 var 不同，let 关键字是块作用域的，这意味着用 let 声明的变量只能在定义的块内访问。在代码中，变量letTest是使用let关键字在if语句的内部和外部声明的。正如块作用域所预期的那样，修改 if 块内的 letTest 值只会影响该块内的变量。因此，if 块内的第一个 console.log 显示值 2，而块外的第一个 console.log 保留初始值 1。

• const: Similar to the let keyword, variables declared with const are also block-scoped. The code declares the variable constTest as a constant inside and outside the if statement. Despite being constants, the block scope allows re-declaration within different blocks. However, reassigning a value to a constant is not allowed. Thus, modifying the value of constTest inside the if block affects only the variable within that block, while the value outside the block remains unchanged.

Misunderstanding Loose and Strict Equality

Mastering the use of equality operators is crucial for JavaScript developers. Unlike other languages that rely on a single type, JavaScript offers two: the strict equality operator and the loose equality operator. Understanding the nuances between these operators is essential for writing robust and error-free JavaScript code.

Loose Equality

The loose equality performs type coercion before comparison. This operator tends to convert the operands to the same type before evaluating the equality. While this may seem convenient, it often leads to unexpected results, especially when comparing different data types.

The loose equality operator in JavaScript follows several basic rules to determine when to perform type coercion:

• If the operands have the same type, In this case, where both have the same type, no coercion is necessary, and the equality comparison gets done.

• If one operand is null and the other is undefined, JavaScript treats null and undefined as equal when using loose equality. Also, null and undefined values can't undergo type coercion, so they are equal.

• If one operand is a number and the other is a string, JavaScript will attempt to convert the string operand to a number before comparing the values.

• If one operand is a boolean, If one operand is a boolean, JavaScript will attempt to convert that operand to the numeric value. The numeric values: the value of false is converted to 0, whereas the value of true is converted to 1.

• If one operand is an object and the other is not, JavaScript will attempt to convert the object operand to a primitive value (using the valueOf and toString methods) before comparing.

• If both operands are objects, JavaScript compares their references to determine whether they are the same object. Note that the references are compared, not their values. Two objects are only equal if they reference the same object in memory.

• If either operand is NaN, the loose equality operator returns false. Note that even if both operands are NaN, you still get false because, by default, NaN is not equal to NaN.

Strict Equality

Strict equality compares both values and types strictly without performing any type coercion. It demands that both operands have the same value and data type for equality to be true. This approach offers clarity and predictability, eliminating the pitfalls of implicit type conversion.

It's of utmost importance to be aware of the potential issues and unexpected outcomes that can arise when using loose equality. To steer clear of these, it is strongly recommended that you always use strict equality when comparing operands. This practice will help you maintain data type integrity throughout your codebase, ensuring a more robust and reliable application.

Here is a code snippet for testing different scenarios with their respective results:

// These snippets showcase how JavaScript's loose and
//strict equality operators behave in various scenarios.

// Testing loose equality
const num1 = 5;
const num2 = "5";

console.log(num1 == num2);

// Testing strict equality:
const num3 = 5;
const num4 = "5";

console.log(num3 === num4); // false

// More examples of loose equality
const value1 = 0;
const value2 = false;

console.log(value1 == value2); // true

// More examples of strict equality:
const value3 = 0;
const value4 = false;

console.log(value3 === value4); // false

// Array comparison with loose equality:
const arr1 = [1, 2, 3];
const arr2 = "1,2,3";

console.log(arr1 == arr2); // true

// Array comparison with strict equality:
const arr3 = [1, 2, 3];
const arr4 = "1,2,3";

console.log(arr3 === arr4); // false

Unneccesary usage of the Else block

JavaScript developers are often fond of adding an else block immediately after an if block, even when the logic inside the else block is essentially the default behaviour or can be handled without the else block. This leads to unnecessary code complexity, which can be simplified by restructuring the code.

An else block is executed when the condition of the preceding if statement is evaluated as false. However, in situations where the else block contains code that can be executed without explicitly checking the condition, using the else block becomes redundant and can be avoided.

Code example:

const isEven = (num) => {
  if (num % 2 === 0) {
    return true;
  } else {
    return false;
  }
}
isEven(4); // true
isEven(3); // false

In this code, the function isEven takes a number as input and checks if it's even. If the number is divisible by two without a remainder, it returns true, indicating that the number is even. Otherwise, it returns false, indicating that the number is odd. However, using the else block is unnecessary because if the condition in the if statement is not met (i.e., the number is not even), the function will naturally reach the next line after the if block without needing an else statement.

Now, without the else statement:

const isEven = (num) => {
  if (num % 2 === 0) {
    return true;
  }
  return false;
}
isEven(4); // true
isEven(3); // false

This code is a more concise version of the first code. It checks if the number is even using the if statement; if it is, it returns true. However, if the number is not even, it will return false. There's no need for an else block because the return false statement will only execute if the condition for the if statement is false.

You can even simplify it further by using an arrow function like this:

const isEven = (num) => {
  return num % 2 === 0;
}

This code further simplifies the logic by directly returning the result of the expression num % 2 === 0. If this expression is evaluated as true, the function returns true, indicating that the number is even. Otherwise, it returns false.

Misusing Mutable and Immutable Types

A developer must understand the difference between mutable and immutable types and how they work under the hood. This segment will take objects as the case study to deeply understand how mutable types work and the mistakes usually made when working with them.

• Mutable types: In JavaScript, mutable types are those whose values can be changed after creation. Examples include objects and arrays.
• Immutable types: Conversely, immutable types are types whose values cannot be changed after creation. Examples include strings, numbers, and boolean values.

Consider the code snippet below to understand how immutable types work in JavaScript:

let x = 2;
let y = x; // y becomes the copy of the value in variable x which is 2
x += 2;
y += 1;
console.log(x, y); //This will return 4, 3

In this code sample, we define a variable x with a value of 2. The variable x holds an immutable type, precisely a number. Once you define an immutable type, you can't change it directly.

The line "let y = x" creates a copy of the variable x value and assigns it to y. It's crucial to understand that y is independent of x; any operations performed on x will not affect y, and vice versa. This concept is fundamental to understanding immutable types.

Understanding Mutable Types and References

Mutable types, such as objects and arrays in JavaScript, behave differently from immutable types. When you assign one variable to another with mutable types, they point to the same underlying data in memory. This means that modifying one variable will directly affect the other, as they share a reference to the same data.

Let's consider a simple array code snippet to illustrate this concept:

let x = [];
let y = x;
x.push(1);
y.push(2);
console.log(x); // output [1, 2]
console.log(y); // output [1, 2]

In the code above, variables x and y are arrays initially empty. When we push elements into x and y, we observe that both arrays end up with the same elements - [1, 2]. Unlike immutable types, this behaviour is because mutable types store a reference to the object rather than the actual value.

Here's a breakdown of what happens in the code snippet:

• Variable Assignment: When we assign y to x, y now references the same array that x points to. No copying of the array's content occurs; both variables reference the same array in memory.
• Modifying the Arrays: When we push elements into either x or y, the modification directly affects the shared array in memory. Both x and y point to this array, so any changes made using either variable get reflected in the shared array.

Real-world Scenario: Misunderstanding Mutable vs Immutable Types

A common mistake occurs when developers mix mutable and immutable types, mainly when dealing with nested objects. Let’s consider the code snippet below:

const developer = {
  name: "John Doe",
  age: 25,
  core: {
    programmingLanguage: "JavaScript",
    framework: "React",
    role: "Frontend Developer",
  },
};

// creating a similar developer but with a different name and language
const developer2 = developer;
developer2.name = "Jane Doe";
developer2.core.programmingLanguage = "TypeScript";

console.log("developer", developer); // {name: 'Jane Doe', age: 25, core: {programmingLanguage: 'TypeScript', framework: 'React', role: 'Frontend Developer"}}
console.log("developer2", developer2); // {name: 'Jane Doe', age: 25, core: {programmingLanguage: 'TypeScript', framework: 'React', role: 'Frontend Developer"}}

When you run the code above, you will notice that developer2, which copies the property of the developer object, modified the developer object, automatically making the two objects identical. Now, I believe you understand why! It is because they are both pointing to the same reference in memory. The question is, "How can you have the two objects without them modifying each other?"

When dealing with objects in JavaScript, a common approach for creating a copy is to use the spread operator (...). However, it's important to note that this method, known as shallow copy, only addresses part of the cloning process.

Consider the use of the spread operator in creating a shallow copy:

const developer2 = { ...developer };

While this method prevents direct modifications to the global object developer, it falls short when dealing with nested objects. Changes to nested properties in the copied object developer2 can still impact the original object developer. For example:

developer2.core.programmingLanguage = "TypeScript";

This modification affects the programmingLanguage value in the nested core object of both developer and developer2.

The reason behind this behaviour lies in how the spread operator operates. It copies the object's properties, but when encountering nested objects, it copies their references rather than their values. As a result, changes to nested objects in the copied version get reflected in the original object due to shared references.

To overcome this limitation and ensure a complete separation between objects, developers turn to a concept known as deep cloning. Deep cloning involves creating a new object with independent values, including nested objects.

In JavaScript, a standard method for deep cloning is using JSON.parse() and JSON.stringify(). To see how this works, replace this line of code:

const developer2 = developer;

With this:

const developer2 = JSON.parse(JSON.stringify(developer));

This new line of code creates a deep clone of the developer object, ensuring that modifications to developer2 do not affect the developer. The JSON.stringify() method converts the object into a string (an immutable type), and then JSON.parse() converts it back into an object, effectively creating a new object with its separate memory reference. Note that there are other methods for performing deep cloning.

The code using deep cloning:

const developer = {
  name: "John Doe",
  age: 25,
  core: {
    programmingLanguage: "JavaScript",
    framework: "React",
    role: "Frontend Developer",
  },
};

// creating a similar developer but with a different name and language
const developer2 = JSON.parse(JSON.stringify(developer));
developer2.name = "Jane Doe";
developer2.core.programmingLanguage = "TypeScript";

console.log("developer", developer); // {name: 'John Doe', age: 25, core: {programmingLanguage: 'JavaScript', framework: 'React', role: 'Frontend Developer"}}
console.log("developer2", developer2); // {name: 'Jane Doe', age: 25, core: {programmingLanguage: 'TypeScript', framework: 'React', role: 'Frontend Developer"}}

Not Understanding the Context of 'this' Keyword: Arrow Functions vs Regular Functions

One common mistake JavaScript developers encounter is not fully grasping the behaviour of the this keyword within arrow functions compared to regular functions. This distinction is crucial as it affects how this is scoped and accessed within different function types.

Sample Code:

function createProgrammingLanguage(name, author) {
  return {
    name,
    author,

    useRegularFunction: function () {
      console.log(`${this.name} was created by ${this.author}`);
    },

    useArrowFunction: () => {
      console.log(`${this.name} was created by ${this.author}`);
    },
  };
}

const javascript = createProgrammingLanguage(
  "JavaScript",
  "Brendan Eich",
);
javascript.useArrowFunction();
javascript.useRegularFunction();

Run the code above in a code editor. If you use an online code editor like CodeSandbox, you will notice that the editor throws an error - "Cannot read properties of undefined (reading 'type')." It points out that the issue is from the useArrowFunction(), but if you are using an IDE like Visual Studio Code or Sublime Text then you would notice that calling the useArrowFunction() method results in this: "JavaScript was created by Brendan Eich" while calling the useRegularFunction() results in this: "undefined was created by undefined".

Explanation of the code Output

The error encountered when running the useArrowFunction method occurs because arrow functions do not have this context; they inherit it from the surrounding lexical scope where they are defined. In this case, since useArrowFunction is defined within createProgrammingLanguage, it refers to the global context (usually a window object in a browser environment) where name, and author are undefined.

On the other hand, useRegularFunction is a regular function defined inside an object literal. Regular functions have their own this context, which is determined by how they are called. In this context, this correctly refers to the object returned by createProgrammingLanguage(), allowing useRegularFunction() to access name and author properties without issues.

The right way to use this in an Arrow function

This solution demonstrates how to correctly use this within an arrow function by leveraging lexical scoping.

function createProgrammingLanguage(name, author) {
  return {
    name,
    author,

    overallFunction: function () {
      console.log(
        `Regular function: ${this.name} was created by ${this.author}`,
      );

      // Arrow function inherits this from the parent function
      const arrowFunction = () => {
        console.log(
          `Arrow function: ${this.name} was created by ${this.author}`,
        );
      };

      arrowFunction();
    },
  };
}

const javascript = createProgrammingLanguage("JavaScript", "Brendan Eich");

javascript.overallFunction();

// Result
// Regular function: JavaScript was created by Brendan Eich
// Arrow function: JavaScript was created by Brendan Eich

Code Explanation

• Regular Function Context: Inside the overallFunction, this correctly refers to the object returned by createProgrammingLanguage(). Therefore, the values are retrieved when accessing this.name and this.author.

• Arrow Function Context: The arrowFunction is defined within overallFunction. Arrow functions inherit this from their surrounding lexical scope, the overallFunction. This inheritance ensures that this within the arrow function refers to the same object as this in the parent regular function. As a result, the arrow function correctly accesses this.name and this.author, producing the desired output without encountering the "Cannot read properties of undefined" error.

By understanding arrow functions' lexical scoping behaviour and leveraging this behaviour to inherit this from the parent function's context, you ensure that arrow functions can access object properties and methods within the appropriate context, resolving issues that result in having the this references being undefined.

Accidentally Creating Memory Leaks

Memory leaks in JavaScript can be subtle and insidious, causing problems on devices with limited memory or in frequently called functions. In JavaScript, memory leaks happen when data is held in memory even though it's no longer needed. The primary cause of memory leaks in JavaScript is often unwanted references. Let's explore some common scenarios, how they lead to memory leaks and the solutions.

• Accidental Global Variables: Accidentally declaring variables in the global scope can lead to memory leaks, as these variables persist as long as the window object exists. Here's an example of a function that mistakenly creates a global variable:

function defineLanaguage() {
  language = "JavaScript"; // Accidental global variable
}

In this code, language becomes a property of the window object ("window.language = 'JavaScript'"). To prevent this and ensure language is scoped correctly, use var, let, or const:

function defineLanaguage() {
  let language = "JavaScript"; // Scoped variable
}

Using a scoped variable ensures that language goes out of scope at the end of the function's execution, preventing memory leaks.

• Interval Timers: Interval timers can cause memory leaks if improperly managed. Consider the following code:

let language = "JavaScript";
setInterval(() => {
  console.log(language);
}, 100);

In this code, the interval timer keeps a reference to the language variable, preventing it from being garbage collected even when not needed. To avoid this, clear the interval timer when it's no longer required:

let language = "JavaScript";
let intervalId = setInterval(() => {
  console.log(language);
}, 100);

// Clear the interval when no longer needed
clearInterval(intervalId);

Clearing the interval ensures the handler function and its references are cleaned up properly.

• JavaScript Closures: Closures in JavaScript can inadvertently cause memory leaks if not managed carefully. Consider the following example:

let outer = function () {
  let language = "JavaScript";
  return function () {
    return language;
  };
};

This closure retains a reference to the language variable, preventing it from being collected as garbage. To avoid this, ensure that closures release unnecessary references:

let outer = function () {
  let language = "JavaScript";
  return function () {
    return language;
  };
};

// Clear the outer function reference when no longer needed
outer = null;

Clearing the reference to the outer function allows the language variable to be garbage collected when it's no longer needed.

By addressing these common scenarios of memory leaks in JavaScript, developers can improve the efficiency and stability of their code. To prevent memory leaks, always scope variables correctly, manage interval timers responsibly, and release unnecessary closures. You can research and see some other instances that lead to memory leaks, but the ones mentioned here are common.

Using Variable has Key in Object Wrongly

One common mistake in JavaScript is improperly using a variable as a key when defining an object literal. This mistake can lead to unexpected behaviour or incorrect object structures. Let's delve into this issue, understand why it occurs, and explore the correct approach to defining object keys dynamically.

In order to understand the mistake, consider the following code snippet:

var type = true;
var language = null;

if (type) {
  language = "TypeScript";
} else {
  language = "JavaScript";
}

var obj = {
  language: "programming language",
};

console.log(obj); // Output - { language: "programming language" }

In the code above, the mistake is using the variable language directly as the object (obj) key. Despite language being dynamically assigned a value based on the type condition, it is interpreted as a literal key language rather than using its value as the key.

Expected Result vs Actual Result

• Expected Result: { TypeScript: "programming language" }
• Actual Result: { language: "programming language" }

Correcting the Mistake

JavaScript provides a syntax using square brackets ([ ]) to use a variable as a dynamic key in an object. This allows for the evaluation of the variable's value as the key.

var type = true;
var language = null;

if (type) {
  language = "TypeScript";
} else {
  language = "JavaScript";
}

var obj = {
  [language]: "programming language",
};

console.log(obj); // Output - { TypeScript: "programming language" }

Explanation of the Solution

• Problem: The original code mistakenly used language as a literal key, resulting in { language: "programming language" }.
• Solution: By enclosing language within square brackets ([ ]) during object declaration, JavaScript interprets it as a dynamic key, using the value of language as the key name ("TypeScript" in this case).

Conclusion

Through this exploration of common JavaScript mistakes, you've gained valuable insights into how to write cleaner, more efficient code.

Keep growing, learning, and building!

以上是开发人员常犯的 JavaScript 错误的详细内容。更多信息请关注PHP中文网其他相关文章！