I am small and live in Wuhan, do two years of new media, ready to use 6 months time to switch to the front end of the industry.

Lesson Objective for today

Yesterday, I learned the parameter improvement of function in ES6 based on search. Yesterday I was going to learn deconstruction today, but it turned out that the strict mode mentioned in function has not been learned yet, so today I will mainly learn the strict mode based on search, which is a good day for learning. Come on, small and ！！！！

Basic instructions

ECMAScript 5’s strict mode is a way to adopt restrictive JavaScript variants that make code appear out of sloppy/sloppy/lazy mode.

The strict pattern is not just a subset: it is created to create semantics that differ from normal code.

Browsers that do not support strict mode behave differently when executing strict mode code than those that do.

Therefore, the adoption of a strict pattern may not achieve the desired results without conducting feature tests on the runtime environment to verify support for the aspects related to the strict pattern. Strict schema code and non-strict schema code can coexist, so project scripts can gradually adopt strict schema.

Strict mode makes some changes to normal JavaScript semantics.

  • Strict modeSome of the original was eliminated by throwing errorsSilent errors.
  • Strict modeFixed some causesJavaScript engineDefects that are difficult to optimize: Sometimes, the same code,Strict modeCan thanStrict modeIt runs faster down.
  • Strict modeDisabled inECMAScriptSome syntax that may be defined in future versions of the.

Major browsers now implement strict mode.

But don’t blindly rely on it, because there are still plenty of browser versions on the market that only partially support strict mode or don’t support it at all (such as pre-IE10 versions).

Strict patterns change the semantics. Relying on these changes can cause problems or errors in browsers that do not implement strict patterns.

Use strict patterns carefully, and ensure that strict patterns do not break by examining the functionality of the relevant code.

Finally, remember to test your code in a browser that supports or does not support strict patterns.

If you only test in browsers that don’t support strict patterns, you’re more likely to have problems in browsers that do, and vice versa.

Turn on strict mode

Strict patterns can be applied to entire scripts or to individual functions.

Do not do this in closed braces {}; this is not effective in such a context. Script strings passed in eval, Function, inline event handling properties, and windowtimers.setTimeout () methods behave like a single script with strict mode turned on, and they work as expected.

Open the script

To enable strict mode for the entire script file, place a specific statement ‘use strict’ before all statements; (or ‘use strict’;)

// Strict mode syntax is enabled throughout the script
'use strict';
const v = "Hi! I'm a strict mode script!";
Copy the code

There’s a catch to this syntax, and Amazon fell for it: You can’t blindly merge conflicting code.

Imagine merging a script in strict mode with a script in non-strict mode: the merged script code appears to be in strict mode.

The reverse is also true: non-strict merge strict looks non-strict.

It is ok to merge both strict and non-strict scripts, but it is only possible to merge strict and non-strict scripts.

It is recommended to start strict mode function by function (at least during the learning transition).

You can also include the contents of the entire script in a function, and then use strict patterns in this external function. Doing so eliminates the merge problem, but it means that you have to declare a global variable outside the function scope.

Function to open

Similarly, to turn a function on strict mode, make “use strict”; (or ‘use strict’;) The declaration precedes all statements in the function body verbatim.

((a)= > {
  const strict = (a)= > {
    // Function level strict schema syntax
    'use strict';
    const nested = (a)= > { return "And so am I!"; }
 return "Hi! I'm a strict mode function! " + nested();  }  const notStrict = (a)= > { return "I'm not strict."; } }) ();Copy the code

Role that

Strict mode changes both syntax and runtime behavior.

Change usually falls into these categories

  • Translate the problem directly toerror(e.g.,Grammar mistakesorRuntime error)
  • Simplified how is givenThe name of theSpecific variable calculation of
  • To simplify theevalAs well asarguments, will write safeJavaScriptthestepsTo become moresimple, as well as changes in predicting the futureECMAScriptA way of behaving.

Turn fault errors into exceptions

In strict mode, some previously accepted errors are considered exceptions. JavaScript is designed to make it easier for new developers to use, so sometimes it gives new non-error semantics to what would otherwise be bad operations.

Sometimes this solves immediate problems, but sometimes it leaves bigger ones for the future. The strict model treats these errors as errors so that they can be discovered and corrected immediately.

Simplify the use of variables

Disable the with

Disable with in strict mode.

The problem with raises is that any name in a block can be mapped to properties of the object passed in with, or to variables (even global variables) in the scope surrounding the block, all of which are determined at run time: you don’t know until the code runs.

In strict mode, using with causes syntax errors, so there is no need for variables inside the with block to decide where to reference at run time:

((a)= > {
  'use strict';
  const x = 17;
  with (obj) // Uncaught SyntaxError: Strict mode code may not include a with statement
  {
 // If strict mode is not enabled, does the x in with refer to the x above with or obj.x?  // We have no way of knowing if we don't run the code, so the code prevents the engine from optimizing and slowing down.  x;  } }) ()Copy the code

An easy way to replace with is to assign the target object to a short named variable and then access the corresponding properties on that variable.

Introducing new variables

Eval in strict mode no longer introduces new variables into the surrounding scope.

In normal mode, the code eval(“var x;” Is most clearly observable in the surrounding function or globally, introducing a new variable x.

This means that, in general, all names that do not refer to arguments or local variables in a function that contains eval calls must be mapped to a particular definition at runtime (because new variables that Eval may introduce overwrite its outer variables).

In strict mode eval only creates variables for the code being run, so eval does not map names to external variables or other local variables

((a)= > {
  const {assert, log} = console;
  const x = 17;
  const evalX = eval("'use strict'; const x = 42; x");
log(assert(x ! = =17.'yes it is 17'));// Assertion failed: yes it is 17
log(assert(evalX ! = =42.'yes it is 42'));// Assertion failed: yes it is 42 }) ()Copy the code

Accordingly, if the function eval is eval(…) in strict mode When called as an expression, the code is executed as if it were in strict mode.

It is possible to explicitly turn on strict mode in your code, but this is not required.

((a)= > {
  const { log } = console;
  const strict1 = (str) = >{
    'use strict';
    return eval(str); // The code in STR runs in strict mode
 }  const strict2 = (f, str) = >{  'use strict';  return f(str); // No direct call to eval(...) : if and only if the code in STR is in strict mode  // Run in strict mode  }  const nonStrict = (str) = >{  return eval(str); // The code in STR will run in strict mode only if and only if "use strict" is turned on  }   log(strict1("'Strict mode code! '")); // Strict mode code!  log(strict1("'use strict'; 'Strict mode code! '")); // Strict mode code!  log(strict2(eval."'Non-strict code.'")); // Non-strict code.  log(strict2(eval."'use strict'; 'Strict mode code! '")); // Strict mode code!  log(nonStrict("'Non-strict code.'")); // Non-strict code.  log(nonStrict("'use strict'; 'Strict mode code! '")); // Strict mode code! }) ()Copy the code

Thus, a variable in strict mode code where EVAL is executed behaves the same as a variable in strict mode code where eval is not executed.

Strict mode disallows deletion of declared variables

Delete name causes a syntax error in strict mode

((a)= > {
  'use strict';

// const x; // Uncaught SyntaxError: Missing initializer in const declaration
  let x;
 delete x; // Uncaught SyntaxError: Delete of an unqualified identifier in strict mode.   // Uncaught SyntaxError: Delete of an unqualified identifier in strict mode.  eval("let y; delete y;"); }) ()Copy the code

The strict controlevalandarguments

Strict mode makes arguments and Eval less weird.

Both involve a lot of weird behavior in normal code: Eval adds and removes bindings, changes bound values, and modifies parameters by aliasing them with properties it indexes.

While there won’t be a complete fix until a future version of ECMAScript resolves this issue, having Eval and arguments as keywords in strict mode is helpful.

The names eval and arguments cannot be bound or assigned by program syntax. Any of the following attempts will cause a syntax error:

((a)= > {
  'use strict';
  eval = 17; // Uncaught SyntaxError: Unexpected eval or arguments in strict mode
  arguments+ +;// Uncaught SyntaxError: Unexpected eval or arguments in strict mode
  ++eval; // Uncaught SyntaxError: Unexpected eval or arguments in strict mode
 const obj = { set p(arguments) { } }; // Uncaught SyntaxError: Unexpected eval or arguments in strict mode  const eval; // Uncaught SyntaxError: Unexpected eval or arguments in strict mode  try{}catch (arguments) {}// Uncaught SyntaxError: Unexpected eval or arguments in strict mode  function x(eval) {}// Uncaught SyntaxError: Unexpected eval or arguments in strict mode  function arguments() {}// Uncaught SyntaxError: Unexpected eval or arguments in strict mode  const y = function eval() {};// Uncaught SyntaxError: Unexpected eval or arguments in strict mode  const f = new Function("arguments"."'use strict'; return 17;"); // Uncaught SyntaxError: Unexpected eval or arguments in strict mode }) ()Copy the code

Arguments object property updates

In strict mode, the value of arguments does not change with the value of the arguments object.

In normal mode, for functions whose first argument is arg, assignments to arg are also assigned to arguments[0] and vice versa (unless there are no arguments, or arguments[0] is removed). In strict mode, the arguments object for a function holds the original arguments to which the function was called.

Arguments [I] do not change as arguments change, nor do arguments with the same name change as arguments[I].

((a)= > {
  const {assert} = console;
  function f(a){
    'use strict';
    a = 42;
 return [a, arguments[0]]. }  const pair = f(17);  assert(pair[0= = =42);  assert(pair[1= = =17); }) ()Copy the code

Arguments object and function properties

In strict mode, calls to Arguments. callee, arguments.caller, anyFunction.caller, and anyFunction.arguments raise exceptions.

arguments.callee

In normal mode, arguments.callee points to the currently executing function. This is so small that the only legitimate use should be to declare anonymous functions and reuse them.

In addition, arguments.callee is very detrimental to optimizations, such as inline functions, because arguments.callee relies on references to non-inline functions.

In strict mode, arguments.callee is a non-deletable property, and exceptions are thrown when assigned and read.

// example taken from vanillajs: http://vanilla-js.com/
const s = document.getElementById('thing').style;
s.opacity = 1;
(() = >{
  if((s.opacity-=1.) < 0) { s.display="none";  }  else{  setTimeout(arguments.callee, 40);  } }) ();Copy the code

This can be rewritten as:

((a)= > {
  'use strict';
  const s = document.getElementById('thing').style;
  s.opacity = 1;
  (function fadeOut(){ // name the function
 if((s.opacity-=1.) < 0) { s.display = "none";  }else{  setTimeout(fadeOut, 40); // use the name of the function  } }) ();}) ();Copy the code

arguments.caller

In some older ECMAScript implementations, Arguments. caller used to be an object that stored properties pointing to variables of that function.

This is a security risk because it breaks reserved values that would otherwise be hidden through function abstraction; It is also the cause of a lot of optimization work.

For these reasons, current browsers don’t implement it. Caller is also an attribute that cannot be deleted in strict mode because of its legacy function, and an error is reported when assigning or taking a value

((a)= > {
  'use strict';
  function fun(a, b)
  {
 'use strict';
 var v = 12;  return arguments.caller; // Throws a type error  }  fun(1.2); // Does not expose v (or A, or B) }) ();Copy the code

anyFunction.caller

In strict mode it is no longer possible to navigate the JavaScript stack with a widely implemented ECMAScript extension.

With these extensions in normal mode, fun.caller is the last function to call fun when a function called fun is being called, and fun.arguments contains the parameters used to call fun.

Both of these extension interfaces are problematic for secure JavaScript because they allow secure code to access proprietary functions and their (often unprotected) parameters.

If fun is in strict mode, fun.caller and fun.arguments are non-deletable attributes and will return an error when storing or taking values

((a)= > {
  function restricted()
  {
    'use strict';
    // Script snippet #6:5 Uncaught TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
 restricted.caller; // Throws a type error  restricted.arguments; // Throws a type error  }  function privilegedInvoker()  {  return restricted();  }  privilegedInvoker(); }) ();Copy the code

“Safe” JavaScript

It’s easier to write secure JavaScript in strict mode.

Some sites now provide a way for users to write JavaScript code that can be executed by other users of the site.

In the browser environment, JavaScript is able to access the user’s private information, so this type of JavaScript must be partially converted before running to require access to disabled functions.

There are not many run-time checking cases, and the flexibility of Javascript prevents it from doing this efficiently.

Functions in some languages are so common that checking them at execution time can cause serious performance losses.

Making small changes that occur in strict mode, requiring user-submitted JavaScript to be turned on in strict mode and called in a specific way, greatly reduces the need for checking at execution time.

A value passed to a function through this in strict mode is not cast to an object.

For a normal function, this is always an object: it is always an object when called; This is the object wrapped inside the function when you call it with a Boolean, string, or number; Use undefined or null to call the global object represented by the function this (use call, apply, or bind to specify a definite this).

Not only is this automatic conversion to objects a performance drain, but exposing global objects in the browser is a security risk because global objects provide access to functionality that a supposedly secure JavaScript environment must restrict.

So for a function in strict mode, the specified this is no longer wrapped as an object, and it is undefined if this is not specified.

((a)= > {
  const { assert, log } = console;
  'use strict';
  function fun() { return this; }
  log(fun());// Window {ƒ : ƒ, blur: ƒ, focus: ƒ, close: ƒ, frames: Window,... }
 assert(fun() === undefined.'it is not undefined');// Assertion failed: it is not undefined  log(fun.call(2));// Window {ƒ : ƒ, blur: ƒ, focus: ƒ, close: ƒ, frames: Window,... }  assert(fun.call(2) = = =2.'it is not 2');// Assertion failed: it is not 2  log(fun.apply(null));// Window {ƒ : ƒ, blur: ƒ, focus: ƒ, close: ƒ, frames: Window,... }  assert(fun.apply(null) = = =null.'it is not null');// Assertion failed: it is not null  log(fun.call(undefined));// Window {ƒ : ƒ, blur: ƒ, focus: ƒ, close: ƒ, frames: Window,... }  assert(fun.call(undefined) = = =undefined);// Assertion failed: it is not undefined  log(fun.bind(true));ƒ fun() {return this; }  assert(fun.bind(true) () = = =true.'it is not true');// Assertion failed: it is not true }) ();Copy the code

Paves the way for future norms

Pave the way for future versions of ECMAScript

It is likely that future versions of ECMAScript will introduce new syntax, and ECMAScript5’s strict schema sets some restrictions early on to mitigate the impact of future version changes. If the protection mechanism in strict mode is used early, it becomes easier to make changes.

The reserved keyword is added

Some characters become reserved keywords in strict mode.

These characters include implements, interface, let, package, private, protected, public, static, and yield.

In strict mode, you can no longer use these names as variable names or parameter names.

((a)= > {
  function package(protected){ / /!!!!!!
    'use strict';
    var implements; / /!!!!!!

 interface: / /!!!!!!  while (true)  {  break interface; / /!!!!!!  }   function private() {}/ /!!!!!!  }  function fun(static) { 'use strict'; } / /!!!!!! }) ();Copy the code

Two caveats to Mozilla development: First, if your JavaScript version is 1.7 or higher (your Chrome code or you use

loaded code, let or yield will not be used as keywords;

Second, while ES5 retains the class, enum, export, extends, import, and super keywords unconditionally, Mozilla retained them only in strict mode prior to Firefox 5.

Disallow internal function declarations

Strict mode prohibits function declarations that are not at the script or function level.

In normal browser code, function declarations are legal everywhere.

This is not in the ES5 specification (or even ES3)! This is an extension of the different semantics found in different browsers.

A future version of ECMAScript will hopefully include a new syntax for function declarations that do not occur at the script or function level.

Banning such function declarations in strict mode clears the way for future releases of ECMAScript:

((a)= > {
  'use strict';
  if (true) {    function f() {}/ /!!!!!! Grammar mistakes
    f();
 }   for (var i = 0; i < 5; i++){  function f2() {}/ /!!!!!! Grammar mistakes  f2();  }   function baz() { / / legal  function eit() {}// Also legal  } }) ();Copy the code

This prohibition in strict mode is not very appropriate, since such function declarations are an extension of ES5. But this is what the ECMAScript committee recommends, and it’s implemented in Mozilla, but not in Chrome.

Mistakes show

Grammar mistakes

If strict mode is turned on in code with ‘use strict’, the following cases raise SyntaxError before the script runs:

  • Octal syntax:const n = 023andconst s = "\047".
  • withStatements.
  • usedeleteTo delete aThe variable name(rather thanThe property name) :delete myVariable.
  • useevalorargumentsAs aThe variable nameorThe function name.
  • useFuture reserved wordMaybeECMAScript 6The use of) :implements.interface.let.package.private.protected.public.static, andyieldAs aThe variable nameorThe function name.
  • inblockThe use ofFunction declaration:if(a<b){ function f(){} }.
  • Other errors
    • Object literalsUse two identical ones inThe property name:{a: 1, b: 3, a: 7}.
    • A function parameterUse two identical ones inParameter names:function f(a, b, b){}.

These errors are beneficial because they reveal crude errors and bad practices that are thrown before the code runs

Global variables can no longer be accidentally created in strict mode

Assigning a value to a misnamed variable name in normal JavaScript causes the global object to add a property and continue working (although this may fail in the future: it can in modern JavaScript).

An error was thrown instead of accidentally creating a global variable in strict mode:

((a)= > {
  'use strict';
  mistypedVaraible = 17;
  // This line of code raises a ReferenceError
  // Uncaught ReferenceError: mistypedVaraible is not defined
}) ()Copy the code

The nuptial properties

Prior to Gecko version 34, strict schema required that all attribute names within an object must be unique within the object. In normal mode, duplicate attributes are allowed. The duplicate parameter name obscures the previous duplicate parameter, and the last duplicate attribute determines its attribute value.

The previous arguments are still accessible via arguments[I], but are not completely inaccessible.

Because only the last property works, copying the object creates a chain of bugs when the code changes the value of the property rather than the last property with the same name.

However, this concealment is meaningless and may be unexpected (for example, it could have been a typo), so duplicate parameters are considered syntactic errors in strict mode.

An error was thrown instead of accidentally creating a global variable in strict mode:

'use strict';
MistypedVariable mistypedVariable
mistypedVaraible = 17; // Because the variable name is misspelled
// This line of code raises a ReferenceError
// Uncaught ReferenceError: mistypedVaraible is not defined
Copy the code

Runtime error

JavaScript used to fail silently in certain situations in certain contexts, and strict mode would throw errors in those situations.

If your code contains such scenarios, be sure to test to make sure no code is affected.

Again, strict mode can be set at code granularity.

Undeclared variable assignment

((a)= > {
  const f = (x) = > {
    'use strict';
    const a = 12;
    b = a + x*35; // Uncaught ReferenceError: b is not defined
 }  f(); }) ()Copy the code

Changing the value of a global object can have unexpected consequences.

If you really want to set the value of a global object, treat it as a parameter and explicitly treat it as a property:

((a)= > {
  const global = this;
  // in the top-level context,
  // "this" always refers the global object
  const f = (x) = > {
 'use strict';  const a = 12;  global.b = a + x * 35;  }  f(); }) ()Copy the code

An attempt was made to remove a non-configurable property

((a)= > {
  'use strict';
  delete Object.prototype; // Uncaught TypeError: Cannot delete property 'prototype' of function Object() { [native code] }
}) ()Copy the code

In non-strict mode, such code would only silently fail, which could lead the user to mistakenly believe that the deletion succeeded.

Attempt to modify an unmodifiable variable

((a)= > {
  'use strict';
  NaN = 111; // Throws TypeError
  // Uncaught TypeError: Cannot assign to read only property 'NaN' of object '#<Window>'
}) ()Copy the code

In non-strict mode, such code only silently fails, which can lead the user to mistakenly believe that the modification succeeded.

An attempt was made to modify a non-configurable property

Any assignment operation that causes silent failure in normal mode (to an unwritable property, to a getter-only property, to new properties of a non-extensible Object) throws an exception:

((a)= > {
  'use strict';
  // Assign a value to an unwritable attribute
  const obj1 = {};
  Object.defineProperty(obj1, "x", { value: 42.writable: false });
 obj1.x = 9; // Throws TypeError  // Uncaught TypeError: Cannot assign to read only property 'x' of object '#<Object>'   // Assign a read-only attribute  const obj2 = { get x() { return 17; }}; obj2.x = 5; // Throws TypeError  // Uncaught TypeError: Cannot set property x of #<Object> which has only a getter   // Assign a new attribute to an unextensible object  const fixed = {};  Object.preventExtensions(fixed);  fixed.newProp = "ohai"; // Throws TypeError  // Uncaught TypeError: Cannot add property newProp, object is not extensible }) ()Copy the code

In non-strict mode, such code will only silently fail, which may cause the user to mistakenly believe that the setup operation succeeded.

Strict mode requires that function parameter names be unique

In normal mode, the last duplicated parameter name obscures the previous duplicated parameter name.

The previous arguments are still accessible via arguments[I], but are not completely inaccessible.

However, this concealment is meaningless and may be unexpected (for example, it could have been a typo), so in strict mode duplicate arguments are considered syntactic errors:

((a)= > {
  // Uncaught SyntaxError: Duplicate parameter name not allowed in this context
  const sum = (a, a, c) = > { / /!!!!!! Grammar mistakes
    'use strict';
    return a + a + c; // The code runs here in error
 } }) ()Copy the code

Strict mode in ECMAScript 6 forbids setting attributes for primitive values.

Without strict mode, setting properties is simply ignored (no-op), and in strict mode, TypeError is thrown

((a)= > {
  'use strict';

  false.true = "";              // Uncaught TypeError: Cannot create property 'true' on boolean 'false'
  (14).sailing = "home";        // Uncaught TypeError: Cannot create property 'sailing' on number '14'
 "with".you = "far away"; // Uncaught TypeError: Cannot create property 'you' on string 'with'  }) ();Copy the code

ES6 changes

ES2016 has changed a bit, stating that functions cannot be explicitly set to strict mode internally if they use default values, destructed assignments, or extended operators. Otherwise, an error will be reported.

((a)= > {
  / / an error
  const doSomething = (a, b = a) = > {
    'use strict';
    // code
 // Uncaught SyntaxError: Illegal 'use strict' directive in function with non-simple parameter list  }   / / an error  const doSomething = ({a, b}) = > {  'use strict';  // code  // Uncaught SyntaxError: Illegal 'use strict' directive in function with non-simple parameter list  };   / / an error  const doSomething = (. a) = > {  'use strict';  // code  // Uncaught SyntaxError: Illegal 'use strict' directive in function with non-simple parameter list  };   const obj = {  / / an error  doSomething({a, b}) {  'use strict';  // code  // Uncaught SyntaxError: Illegal 'use strict' directive in function with non-simple parameter list  }  }; }) ()Copy the code

The reason for this is that strict patterns within functions apply to both function bodies and function parameters.

However, when a function is executed, its arguments are executed first, and then its body.

The only way to know whether arguments should be executed in strict mode is from the function body, but arguments should be executed before the function body.

The semantic differences

These differences are small differences.

It is possible that unit tests will not be able to capture such subtle differences. It is important that you carefully review your code to ensure that these differences do not affect the semantics of your code.

Fortunately, this careful code review can be largely avoided.

This in the function call

In a normal function call f(), the value of this points to the global object. In strict mode, the value of this refers to undefined.

If thisValue is passed as a primitive value (string, number, Boolean) other than null and undefined when called by call or apply, the value of this becomes the wrapper object corresponding to that primitive value, if thisValue is undefined or Null, the value of this points to the global object.

In strict mode, the value of this is the value of the thisValue parameter without any type conversion.

Arguments object property updates

Arguments object properties do not update synchronously with corresponding parameters

In non-strict mode, changing the value of an index attribute in the Arguments object changes the parameter value corresponding to that attribute, and vice versa.

This makes JavaScript code obfuscation engines harder to read and understand.

Arguments objects are created and initialized as copies of parameters in strict mode, so changes to arguments objects do not affect the parameters.

Eval related distinction

In strict mode,eval does not create new variables in the current scope. In addition, string parameters passed into eval are parsed in a strict fashion.

You need thorough testing to make sure no code is affected. Also, if you’re not trying to solve a very practical solution, try not to use Eval.

Refer to the website

  • transition strict mode: https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Strict_mode/Transitioning_to_strict_mode
  • use strict: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
  • ES5: http://www.ecma-international.org/publications/standards/Ecma-262.htm
  • big website: https://bugzilla.mozilla.org/show_bug.cgi?id=627531
  • big website bug: https://bugzilla.mozilla.org/show_bug.cgi?id=579119
  • Operators delete: https://developer.mozilla.org/zh-CN/docs/JavaScript/Reference/Operators/delete
  • TypeError: https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/TypeError
  • ReferenceError: https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/ReferenceError
  • SyntaxError: https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/SyntaxError

Summary of today’s lesson


Today the mood

Today, I will learn the function strict mode in ES6 mainly based on search. I feel that the page script will be safer when the strict mode is turned on in the code. I hope to learn more about this tomorrow ~~~~


This article is formatted using MDNICE