
The ES6 standard of JavaScript introduced `async-await` to avoid callback hell. Since then, we've been able to write sequential calls to a series of asynchronous functions in a chain and handle errors uniformly at the end of the chain.

```javascript
asyncFun1()
  .then((res1) => {
    //scope 1
    return asyncFunc2(res1)
  })
  .then((res2) => {
    //scope 2
    return asyncFunc3(res2)
  })
  .then((res3) => {
    //scope 3
    return asyncFunc4(res3)
  })
  .....
  .catch((err)=>{console.log(err)})
```

However, there's an issue with this approach: we can't access the result of the previous asynchronous function in the next scope of the chain. For instance, in the example above, we can't access `res1` in scope 2 or `res2` in scope 3.

So, what if we want to pass `res1` to `asyncFunc3` instead of `res2`, or if we want to pass `res2` to `asyncFunc4` instead of `res3`?

To address this, we introduce the `await` mechanism to retrieve results from higher-level asynchronous function calls in the subsequent lower-level ones.

So, our code can be modified as follows:

```javascript
const res1 = await asyncFun1();
const res2 = await asyncFun2(res1);
const res3 = await asyncFun3(res1);
const res4 = await asyncFun4(res2);
```

But this introduces another issue: how do we handle errors when awaiting a Promise?

Consider this function:

```javascript
// The function to calculate a / b.
async function divide(a, b) {
  return new Promise((resolve, reject) => {
    if (b !== 0) resolve(a / b);
    else reject(new Error("The divisor cannot be 0."));
  });
}
```

The standard approach is:

```javascript
try {
  const res = await divide(5, 4);
} catch (err) {
  console.log(err);
}
```

Typically, in JavaScript, we use a `try-catch` block around the await statement to catch errors.

However, there's another problem: TypeScript doesn't support indicating the type of the parameter for the `reject` function. In other words, TypeScript cannot recognize the type of `err` in the above code and treats it as `any`. Even if you pass a specific `Error` class to `reject`, TypeScript still recognizes `err` as `any`.

If `reject` doesn't pass an `Error` but instead a `string`, like this:

```javascript
async function divide(a, b) {
  return new Promise((resolve, reject) => {
    if (b !== 0) resolve(a / b);
    // Reject with string rather than Error here.
    else reject("The divisor cannot be 0.");
  });
}
```

Then, using `try-catch` to catch errors wouldn't be appropriate.

Of course, you can enforce programming standards and conventions in your own projects or libraries to ensure that the parameter passed to `reject` is always a "Catchable Error." But what if you're using a third-party library?

There's another scenario: you have to nest each await statement within a `try-catch` block every time, which leads to poor code flexibility and readability, making it bulky.

```javascript
try {
  const res1 = await asyncFun1();
} catch (err) {
  console.log(err);
}

try {
  const res2 = await asyncFun2();
} catch (err) {
  console.log(err);
}

try {
  const res3 = await asyncFun3();
} catch (err) {
  console.log(err);
}

// ......
```

Let's think of an alternative. Is it possible to create a function that awaits an asynchronous function and returns a tuple, providing the result if resolved and the error if rejected?

That brings us to today's topic: implementing an `await-to` function to uniformly obtain both resolved and rejected results without having to use `try-catch` every time.

```javascript
function to(promise) {
  return new Promise((resolve) => {
    promise.then((res) => resolve([null, res])).catch((err) => resolve([err, null]));
  });
}

// Example Usage
const examplePromise = new Promise((resolve, reject) => {
  // Simulate the Async operation
  setTimeout(() => {
    reject(new Error("Something went wrong"));
  }, 1000);
});

const [err, res] = await to(examplePromise);
console.log([err, res]); // Now it will return the [Error,null]

// Or if the promise is resolved.

// Example Usage
const examplePromise = new Promise((resolve, reject) => {
  // Simulate the Async operation
  setTimeout(() => {
    resolve("Hello");
  }, 1000);
});

const [err, res] = await to(examplePromise);
console.log([err, res]); // Now it will return the [null,"Hello"]
```

This way, we've implemented `await-to`. It's very friendly to annotated error types and the implementation is quite elegant. Of course, this method of handling exceptions resembles GoLang!

There are already packages related to `await-to-js` on npm that you can use out of the box.

```bash
npm i await-to-js
```

[Its source code and examples are open-source on GitHub.](https://github.com/scopsy/await-to-js)


Handling asynchronous function errors and result more elegantly.

The Await-to-Js


## Equals

```typescript
type Equals<T, U> = T extends U ? (U extends T ? true : false) : false;

type Type1 = { a: number; b: string };
type Type2 = { a: number; b: string };
type Type3 = { a: number; c: string };

type Test1 = Equals<Type1, Type2>; // true
type Test2 = Equals<Type1, Type3>; // false
```

## If

```typescript
type If<C extends boolean, T, F> = C extends true ? T : F;

type A = If<true, "a", "b">; // expected to be 'a'
type B = If<false, "a", "b">; // expected to be 'b'
```

## Includes

```typescript
type Includes<T extends any[], U> = {
  [K in T[number]]: true;
}[U] extends true
  ? true
  : false;

type MyType = Includes<["Kars", "Esidisi", "Wamuu", "Santana"], "Dio">;
// expected to be `false`
```

## Merge

```typescript
type Merge<T> = {
  [P in keyof T]: T[P];
};
```

## Diff

```typescript
type Diff<O, O1> = Merge<
  {
    [P in Exclude<keyof O, keyof O1>]: O[P];
  } & {
    [P in Exclude<keyof O1, keyof O>]: O1[P];
  }
>;
```

## Ranged Number

```typescript
type IsMore<A extends number, B extends number, L extends any[] = []> = A extends L["length"]
  ? false
  : B extends L["length"]
    ? true
    : IsMore<A, B, [...L, any]>;
type NumRange<Max, Min> = isMore<infer U, Min> extends true ? (isMore<Max, U> extends true ? U : never) : never;

type MyType = NumRange<1000, 9999>;
// Only number 1000-9999 can be accepted.
```

## Tuple To Union

```typescript
type TupleToUnion<T extends any[]> = T[number];

type Arr = ["1", "2", "3"];
const test: TupleToUnion<Arr>; // expected to be '1' | '2' | '3'
```

## String To Union

```typescript
type StringToUnion<T extends string> = T extends `${infer First}${infer Reset}` ? First | StringToUnion<Reset> : never;
type Test = "123";
type Result = StringToUnion<Test>; // expected to be "1" | "2" | "3"
```

## Length of String

```typescript
type LengthOfString<S extends string, T extends any[] = []> = S extends `${infer L}${infer R}`
  ? LengthOfString<R, [...T, L]>
  : T["length"];

type MyType = LengthOfString<"hello">; // 5
```


TypeScript Type-Exercises-3


## Spilt String into Chars

```ts
type Split<T extends string, U extends unknown[] = []> = T extends `${infer F}${infer Rest}`
  ? Split<Rest, [...U, F]>
  : U;

type MyType = Split<"abcdef">;
// MyType = ["a", "b", "c", "d", "e", "f"]
```

## Trim, TrimStart, TrimEnd

```ts
type TWhiteSpace = " " | "\n" | "\t";

type TrimStart<S extends string> = S extends `${TWhiteSpace}${infer R}` ? TrimStart<R> : S;
type TrimEnd<S extends string> = S extends `${infer R}${TWhiteSpace}` ? TrimEnd<R> : S;
type Trim<T extends string> = TrimRight<TrimLeft<T>>;

type MyTrimEnd = TrimEnd<"Hello World   ">;
// 'Hello World'
type MyTrimStart = TrimStart<"  Hello World">;
// 'Hello World'
type MyTrim = Trim<"   Hello World   ">;
// 'Hello World'
```

## Lowercase To Uppercase

```ts
type LowercaseToUppercase<L extends string> = L extends `${"a"}${infer R}`
  ? `${"A"}${LowercaseToUppercase<R>}`
  : L extends `${"b"}${infer R}`
  ? `${"B"}${LowercaseToUppercase<R>}`
  : L extends `${"c"}${infer R}`
  ? `${"C"}${LowercaseToUppercase<R>}`
  : L extends `${"d"}${infer R}`
  ? `${"D"}${LowercaseToUppercase<R>}`
  : L extends `${"e"}${infer R}`
  : .....
  : L;

type MyUppercase = LowercaseToUppercase<"hello">;
// MyUppercase = "HELLO"
```

With the akin method, we also make a `UppercaseToLowercase` type definition.

## Capitalize

```ts
type Capitalize<S extends string> = S extends `${infer L}${infer R}` ? `${Uppercase<L>}${R}` : "";

type MyType = Capitalize<"hello world">;
// MyType = 'Hello world'
```

## Replace

```ts
type Replace<S extends string, F extends string, T extends string> = F extends ""
  ? S
  : S extends `${infer L}${F}${infer R}`
    ? `${L}${T}${R}`
    : S;

type MyType = Replace<"this is the test demo", "e", "E">;
// MyType: 'this is thE test demo'
```

It replace the first matched char.

## Replace All

```ts
type ReplaceAll<S extends string, F extends string, T extends string> = F extends ""
  ? S
  : S extends `${infer L}${F}${infer R}`
    ? `${ReplaceAll<L, F, T>}${T}${ReplaceAll<R, F, T>}`
    : S;

type MyType = ReplaceAll<"this is the test demo", "e", "E">;
// MyType: 'this is thE tEst dEmo'
```

Replace all matched chars.

## StartsWith && EndsWith

```ts
type StartsWith<T extends string, U extends string> = T extends `${U}${string}` ? true : false;
type EndsWith<T extends string, U extends string> = T extends `${string}${U}` ? true : false;

type a = StartsWith<"abc", "ac">; // false
type b = StartsWith<"abc", "ab">; // true
type c = StartsWith<"abc", "abcd">; // false
```

## Repeat String

```ts
type RepeatString<
  Input extends string,
  Count,
  AuxArr extends Input[] = [],
  Result extends string = "",
> = AuxArr["length"] extends Count ? Result : RepeatString<Input, Count, [Input, ...AuxArr], `${Input}${Result}`>;

type MyType = RepeatString<"hello", 3>;
// 'hellohellohello'
```


There are some type exercise about string literal type.

TypeScript Type-Exercises 2


- Template String

```ts
type URL:`https://${string}:${port}`
let a1:URL = 'https://google.com:443' // ok
let a2:URL = 'https://test' // error
```

## Get the return type of the function

```ts
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

type T2 = ReturnType<() => string>; // T2 = string
const sum = (a: number, b: number): number => a + b;
type T3 = ReturnType<sum>; // T3 = number
```

## Get the parameters type list

```ts
type Parameters<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never;

type Func = (a: number, b: string) => void;
type Params = Parameters<Func>;
// Params = [number, string]
```

**Note:** For above two examples they showed the keyword `infer`'s usage. \
Namely you can treat them as a variable that contain the correspond type. \
For example, in `type Parameters<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never` , the `infer P` means storing the types of `...args` into `P` and assigns `P`'s value to the `Parameters` if `T` is an function.

## Restrict the variable equals to one of the elements in an Tuple

```ts
const myTuple = ["a", 100, false] as const;

type MyType = (typeof myTuple)[number];

let myVar: MyType;
// myVar could only be 'a', 100 or false
```

**Note:** In this example the `myTuple` was perceived an readonly tuple and every element are its literal type, namely the first element is the `'a'` type rather then `string`. If you want to make `MyType = string | number | boolean` you can remove the `as const` assertion.

## Equal to the first element in a specified tuple.

```ts
type First<T extends any[]> = T extends [infer F, ...infer R] ? F : never;

type MyType = First<["a", 100, false]>;
// MyType = 'a'
```

## Awaited. Get the type `T` of `Promise<T>`

```ts
type Awaited<T extends Promise<any>> = T extends PromiseLike<infer L> ? L : never;

const asyncFunc = async () => {
  return true;
};
type MyType = Awaited<asyncFunc>;
// MyType = boolean.
```


TypeScript Type-Exercises 1


[The introduction for functions compose is here](/post/functions-compose).

> **Definition : Functions Compose** \
> compose = (funa, funb) => (c) => funa(funb(c));

Now we are supposed to give the proof and derivation process of the following conclusions

> **Associate Law For Functions Compose** \
> compose((funa, funb), func)) = compose(funa, (funb, func))

It's simple to prove this proposition with the definition of functions compose.

according to

```javascript
compose(a, b) = (D) => a(b(D));
```

We assign the argument `b` with

```javascript
b = compose(x, y);
```

So we get

```javascript
compose(a, b) = compose(a, compose(x, y))
= (D) => a(compose(x, y))
= (D) => a(x(y(D)))
```

We find that

```javascript
(D) => a(x(y(D)))
= (D) => compose(compose(a,x),y)
```

So we have the conclusion

```javascript
compose(compose(a, x), y) = compose(a,compose(x, y));
```

QED.

We logically have the expanded conclusion: If there are n function combinations

$$
compose(...,a_{i},a_{i+1},...,compose(a_{j},a_{j+1},...),...,a_{n}) \\ = compose(...,a_{x},a_{x+1},...,compose(a_{y},a_{y+1},...),...,a_{n}); \\
i,j,x,y∈(0,n];

j-i = y-x
$$

The proof of this proposition is omitted.


The derivation process for functions compose

Associate Law For Functions Compose


The `function compose` borrowed thinking from pipeline in Unix-Shell Programming with taking out of a function's output as other function's input.

For example,

```bash
# The content of test.txt is 'Hello'
cat test.text | grep 'World'
# Output : Hello World
```

At above example the symbol `|` is treated as pipeline operator, it transfer the left output to right input.

So the compose in Functional Programming is simply defined as following implement in javascript

```javascript
const compose = (funa, funb) => (c) => funa(funb(c));
```

The compose function accepts two functions as arguments and returns new function that accepts an initial input and applys functions one by one.

In fact the above definition has same effects with

```javascript
const temp = funb(data);
const result = funa(temp);
```

Bear in mind that the order of function calls is inside out and appears in `compose` function is from right to left.

We also have expansion definition for multiple functions compose

```javascript
const composeN =
  (...funcs) =>
  (data) =>
    reduce(funcs.reverse(), (acc, fn) => fn(acc), value);
```


Definitions and examples for Functions Compose

Functions Compose


### Unary, Binary and Variadic

**Definition :** The function that only applies and receives one argument value.

For example, this is a typical unary

```javascript
const func = (para) => para;
```

Corresponding the defination of **Binary** : The function that applies and receives two argument values. We could expand this defination into the **Variadic** : The function that applies and recieves multiple argument values.

```javascript
const add = (x, y) => x + y; // Binary Function
const sum = (...args) => args.reduce((acr, cur) => acr + cur); // Variadic Function
```

### Currying

**Definition :** The currying is the process that transform a variadic into a nested unary.

It may be difficult to understand only by reading at this definition. Here is a detailed explanation by example.

We have an add function:

```javascript
const add = (a, b) => a + b;
```

It applies two argument values to get its sum. But if we need to apply this function for multiple arguments, it should be rewrite as:

```javascript
const add = (...args) => {
  let sum = 0;
  for (val of args) {
    sum += val;
  }
  return sum;
};
```

However, it pulls in a temporary variable `sum` to store the amount while traversing the array, it also called as `State`.

The one of the principles in functional programming is avoid pulling state into program for it may make effects, which causes bugs to make harder debugging.

So we should remove the state variable `sum` by currying.

For example, the Binary function of sum :

```javascript
const add = (a, b) => a + b;
```

We rewrite it such as:

```javascript
const add = (a) => (b) => a + b;
```

When I want to get the sum of 2 and 3:

```javascript
add(2)(3); // 5
```

The function calling process:

```javascript
add(2); // return a function (b) => (b + 2)
add(2)(3); // call to a function returned by the previous layer (3) => (3 + 2) , the b is assigned as 3.
```

Similarly, if we have three arguments, the currying should like:

```javascript
const add = (a) => (b) => (c) => a + b + c;
```

The javascript supports variadic functions, we could derive a generator functions for currying:

```javascript
const curry = (func) => {
  if (typeof func !== "function") {
    return;
  }
  return function curriedFn(...args) {
    if (args.length < func.length) {
      return curriedFn.apply(null, args.concat([].slice.call(arguments)));
    }
    func.apply(null, args);
  };
};
```

So we can curry a variadic functions by function `curry`;

```javascript
const add = (a, b, c) => a + b + c;
const curriedAdd = curry(add);
curriedAdd;
curriedAdd(1)(2)(3); // 6
```


Definitions and examples for Functions Currying

Functions Currying


### **What is IPC?**

> Inter-Process Communication (IPC) refers to some technologies or methods for transmitting information or signals between at least two processes or threads.

The above description comes from WIKI, which means that the method of transmitting information between Main Process and BrowserWindow is IPC.

### **How does IPC work in Electron?**

Electron provides IpcRenderer and IpcMain to facilitate engineers to perform IPC

- Screen side (BrowserWindow) uses IpcRenderer
- The main process side (Main Process) uses IpcMain

### **How to write the code in practice ?**

Shown below are 3 modes of communication

- Someone else will pick you up

IpcMain.on monitors messages from IpcRenderer.send
Then use `event.reply` to return
For example: after you bring the kitten home, you ask the mother to help take care of your kitten and let her help feed it.

![](https://picx.zhimg.com/v2-a234ef76d5c002bb4601dc9113198aaf_720w.jpg?source=d16d100b)

```js
// main.js In main process
const { ipcMain } = require("electron");
ipcMain.on("take-cat-home-message", (event, arg) => {
  console.log(arg); // prints "Bring cub cat to home"
  event.reply("need-clean-reply", "The cub cat is hungry");
});

// preload.js - In renderer process
const { ipcRenderer } = require("electron");
ipcRenderer.on("need-clean-reply", (event, arg) => {
  console.log(arg); // prints "The cub cat is hungry"
});
ipcRenderer.send("take-cat-home-message", "Bring cub cat to home");
```

- Wait for response
  You have been staring at the kitten because you are afraid that she will be hungry, but you have not done anything in the meantime.

![](https://picx.zhimg.com/v2-f9a1f74240929244763eb48a109a54e5_720w.jpg?source=d16d100b)

```js
// main.js - In main process
const { ipcMain } = require("electron");
ipcMain.on("take-cat-home-message", (event, arg) => {
  console.log(arg); // prints "Bring cub cat to home"
  // Before the event respond you are paying attention the cub cat
  event.returnValue = "The cub cat is hungry";
});

// preload.js - In renderer process
const { ipcRenderer } = require("electron");
console.log(ipcRenderer.sendSync("take-cat-home-message", "Bring cub cat to home")); // prints "The cub cat is hungry"
```

- Notification response
  When you clean the house, The cub cat is hungry and will "meow"

![](https://picx.zhimg.com/v2-fc0a4a0cf5b918aa365e57f9e3e123fc_720w.jpg?source=d16d100b)

```js
// main.js - In main process
const { ipcMain } = require("electron");
ipcMain.handle("take-cat-home-handle", async (event, arg) => {
  console.log(arg); // prints "Bring cub cat to home"
  return "The cub cat is hungry, meow";
});

// preload.js - In renderer process。
const { ipcRenderer } = require("electron");
ipcRenderer
  .invoke("take-cat-home-handle", "Bring cub cat to home")
  // Then you can do other things before returning, such as cleaning your home.
  .then((msg) => console.log(msg)); // prints "The cub cat is hungry, meow"
```

The above three methods all start from the renderer process side. What should I do if I want to trigger the message from the main process?

![](https://pic1.zhimg.com/v2-d3cddd53f2c3f55b20d574fa0734e922_720w.jpg?source=d16d100b)

```js
// main.js - In main process
mainWindow.webContents.send("switch-cat", number);

// preload.js - In renderer process
const { ipcRenderer } = require("electron");
ipcRenderer.on("switch-cat", (event, args) => switchCat(args));
```

## **References**

- [Official Documentation ipc-main](https://www.electronjs.org/docs/api/ipc-main)


IPC, Inter-Process Communication, I's said that some technologies or methods for transmitting information or signals between at least two processes or threads. The above description comes from WIKI, which means that the method of transmitting information between Main Process and BrowserWindow is IPC.

Electron: Some IPC Ways


_This post was [transported from zhihu answer](https://www.zhihu.com/question/528539234/answer/2444609012)._

_And origin question is:_

> In js, when a function is executed, it will be destroyed, and correspondingly, the scope of this function will also be destroyed. The form of closure is to return the function in the function, then use a variable in the global to accept the returned function, because the global variable will not be destroyed, and this variable holds the address of the returned function, so we can use this return function, because as long as there are variables or other things used inside the function, then this function will not be destroyed. So when we use the returned function in the global scope, then the main function will not be destroyed, the scope naturally exists, we can naturally use the variables in the function, and can save the state. I don't know if I understand it this way, right?

---

## Here is origin answer

> The form of closure is to return the function in the function, then use a variable in the global to accept the returned function, because the global variable will not be destroyed, and this variable holds the address of the returned function, so we can use this return function, because as long as there are variables or other things used inside the function, then this function will not be destroyed. So when we use the returned function in the global scope, then the main function will not be destroyed, the scope naturally exists, we can naturally use the variables in the function, and can save the state.

What you said is a so long paragraph, so let me first try to break down your understanding, and then analyze it slowly.

You say

> The form of closure is the return function in the function

That is wrong. JavaScript was originally designed with functional programming in mind, where functions are first-class citizens in the language. This means that functions can be stored in variables like any other type, passed as arguments to other functions, or returned as function execution values. **The function returns a function, which is determined by the language paradigm. Nothing to do with closures.**

**So to understand what the form of closure is, we must start with the definition. Its definition is given directly below,**

> A closure occurs when a function is executed outside of the lexical scope in which it was defined and can also remember and access the lexical scope in which it was defined.

According to the above definition, we can know the two characteristics of the closure,

- First, it executes outside the lexical scope in which it was defined.

- Second, it also has access to the lexical scope where it was defined.

It's a bit of a mouthful to say so, so let's give an example to illustrate.

first example,

```javascript
function fpp() {
  var a = 2;
  function bar() {
    console.log(a);
  }
  return bar;
}

var baz = foo(); // Hey, this is the effect of closure
```

The lexical scope of the `bar` function is within the `foo` function. But if the bar function is called directly outside the `foo` function, the compiler cannot find the definition of `bar` outside the `foo`, and therefore does not recognize `bar`, and will throw an error, indicating that `bar` is undefined. So if you want to execute the `bar` function outside the `foo` function, you can use `bar` itself as a return value, let the `baz` variable outside `foo` receive the `bar` function, and then execute it. In this way, the compiler can know that `bar` is stored in `baz` after `foo` is generated, so that the identity of `bar` is clear: it is a function. It can be executed outside of `foo`.

But according to the language setting of JavaScript, when a function is executed, it can access the lexical scope where it is located. For example, functions in the global scope can access global variables. Similarly, when the `bar` function is declared, it can access the scope where it is located, that is, within the `foo` function. And the scope in the `foo` function has a variable `a`, then this a variable can be directly accessed by the `bar` function during execution.

**But isn't this about functions returning functions? Then look at the second example**

```javascript
function foo() {
  var a = 2;
  function baz() {
    console.log(a);
  }
  bar(baz);
}

function bar(fn) {
  fn();
}
```

The `bar` function is declared outside of `foo`, `baz` is defined inside of `foo`, and the `foo` function can access `bar`. Now pass `baz` to the `bar` function, and `bar` will execute it after receiving it. At this time, `baz` is transferred to the scope execution in `bar` by passing, and can access a in the original scope, which is a closure. And it doesn't involve the problem of function returning function.

You see, in the first example above, the **`bar` function is executed after being stored in the `baz` variable outside the lexical scope, and can still access the variable a in the lexical scope, which creates a closure.**In the second example, **`baz` is passed to `bar` through parameters, so that it is executed outside the scope and can access a within the scope. This is also the most essential feature of closures.**

You say

> Because the global variable will not be destroyed, and this variable holds the address of the returned function, so we can use this returned function, because as long as there are variables or other things used inside the function, then this function will not be used destroy.

You are right in saying that global variables are not destroyed. But I don't understand what you want to say, maybe you want to say, as long as the reference of a function is not destroyed, then this function will not be destroyed? **However, in any case, whether the global variable will be destroyed or not has nothing to do with whether the closure will be destroyed...**

In the first example above, `baz` is defined globally. Stored is a reference to bar. `baz` will not be destroyed because it is defined globally, and it does not matter that `bar` and `foo` will not be destroyed.

So back to the second example

```javascript
function foo() {
  var a = 2;
  function baz() {
    console.log(a);
  }
  bar(baz);
}

function bar(fn) {
  fn();
}
```

The `bar` function is declared outside of `foo`, baz is defined inside of `foo`, and the `foo` function can access `bar`. Now pass `baz` to the `bar` function, and `bar` will execute it after receiving it. At this time, `baz` is transferred to the scope execution in `bar` by passing, and can access a in the original scope, which is a closure. **Here, `baz` is executed in the scope of `bar`, not globally, and there is no reference to `baz` in the global. But this is a closure, so `baz` won't be destroyed either.**

The closure will not be destroyed, it is determined by the JavaScript interpreter. **When the interpreter detects that a closure is generated during execution, the lexical scope where the closure is located will be circled by the interpreter and will never be destroyed. It's not because the closure is referenced globally and will not be destroyed, so the closure will not be destroyed either.** It has nothing to do with the global scope.

Understanding closures is a painstaking process. There are many pitfalls in this regard. The terminology of computer programming is more abstract. Therefore, it is recommended that when you come into contact with a concept, it is best to start with the definition and then contact specific examples, rather than start directly with the examples. \*\*Your sentence "the function returns a function" is most likely influenced by some tutorials on the Internet after directly throwing out examples.

Hope my answer is helpful to you.


Give the definition of closure in JavaScript and understand it by examples.

原点日志

JS&TS