
In frontend interaction between components and data state there are some exist and mature thoughts like One-way binding (e.g. React, Svelte) and Two-way binding(e.g. Vue).

Now we will peruse the two-way binding which makes the UI and state automatically update each other.

Here are the graph to differentiate them.

```dot
digraph Binding {
  rankdir=LR;
  node [shape=box, style=rounded];

  subgraph cluster_oneway {
    label="(One-Way Binding)";
    style=dashed;

    State1 [label="State"];
    UI1 [label="UI"];

    State1 -> UI1 [label="Data Flow"];
  }

  subgraph cluster_twoway {
    label="Two-Way Binding";
    style=dashed;

    State2 [label="State"];
    UI2 [label="UI"];

    State2 -> UI2 [label="View Update"];
    UI2 -> State2 [label="Control Flow"];
  }
}
```

## Event Listening + DOM

The earliest two-way binding was done purely manually. For example, for a text input: listen to the DOM's `input`/`change` event, manually update the data, and then manually modify the DOM.

```js
const data = { message: "Hello" };
const input = document.querySelector("#input");
const display = document.querySelector("#display");

// Data -> View
function updateView() {
  input.value = data.message;
  display.textContent = data.message;
}

// View -> Data
input.addEventListener("input", e => {
  data.message = e.target.value;
  updateView();
});

// Initialize
updateView();
```

This is the ancient implementation method, the most intuitive, compatible with all browsers, but cumbersome and high maintenance cost. When the complexity of frontend pages reaches a certain level, the maintenance cost increases exponentially.

## `defineProperty` Data Hijacking

To solve the complexity problem of the above maintenance cost, Vue2 proposed a simple method: utilize JavaScript language features, bind getters and setters, to achieve the effect of automatically updating the view and state bidirectionally.

Before `Proxy` appeared, the most common way was to use `Object.defineProperty` to intercept the object property's `getter / setter`, triggering view updates when setting properties.

The general idea is:

* Use `Object.defineProperty` to hijack the data's getter/setter.
* Collect dependencies in the getter (who uses this data).
* Notify dependencies to update in the setter (Publish-Subscribe pattern).

```js
const data = {};
let value = "Hello";

Object.defineProperty(data, "message", {
  get() {
    return value;
  },
  set(newVal) {
    value = newVal;
    console.log("View updated:", newVal);
    document.querySelector("#input").value = newVal;
  }
});

// Data -> View
data.message = "Hi defineProperty";

// View -> Data
document.querySelector("#input").addEventListener("input", e => {
  data.message = e.target.value;
});
```

This method has good compatibility in IE9+. But the disadvantage is: it can only hijack existing properties; adding/deleting properties cannot be listened to.

## Dirty Checking

Angular.js took a different approach: continuously polling the consistency of the state and view, and then updating the corresponding state and view. This is also called the **Dirty Checking mechanism**: regularly checking whether the data and DOM are consistent, and updating if they are not.

For Angular, its core is a mechanism called the `$digest` loop: whenever data might change (user input, click events, Ajax callbacks, `$timeout`, `$http`, etc., at appropriate times), Angular triggers a dirty check cycle.

During the `$digest` process, Angular checks all Watchers (each bound data corresponds to a watcher) in turn. If it finds that some data is different from the last value, it calls the corresponding callback to update the DOM.

Because updating one piece of data may trigger changes in other data, $digest will run up to 10 times (to prevent infinite loops).

For demonstration convenience, use `setInterval` to temporarily replace polling for dirty checking.

```js
let data = { message: "Hello" };
let oldMessage = data.message;

setInterval(() => {
  if (data.message !== oldMessage) {
    oldMessage = data.message;
    console.log("Update view:", data.message);
    document.querySelector("#display").textContent = data.message;
  }
  // #display is the input component
}, 100);
```

This approach is simple to implement. But the performance is very poor; when involving large-scale data state updates, obvious lag can be felt.

Therefore, in Angular 2.x and later versions, this "two-way binding" idea was abandoned. After using TypeScript, the design philosophy changed to unidirectional data flow + one-way binding. To achieve two-way binding, it must be implemented manually, and Angular also provides corresponding syntactic sugar.

## Proxy

Vue2 implemented reactivity based on `Object.defineProperty`, but there were mainly several problems:

1.  Can only hijack existing properties. You must first define the properties on the object, then use `Object.defineProperty` to add getter/setter. Moreover, operations like adding properties / deleting properties cannot be listened to (Vue2 needed `Vue.set`, `Vue.delete` hacks).
2.  Cannot directly listen to array index changes. Methods like `push/pop/shift/unshift/splice` on arrays need to be rewritten separately. And operations like direct assignment are also not friendly; directly doing `arr[0] = newVal` cannot trigger updates.
3.  Requires recursively traversing the object. Need to add getter/setter to every property at every level of the listened object. However, initializing deeply nested objects is very performance-intensive.

After the ES6 standard was released, Vue3 used `Proxy` to implement reactivity (replacing Vue2's `Object.defineProperty`). Proxy is a relatively new and elegant approach.

Vue3 rewrote the reactivity system using `Proxy`, solving the above problems. The `getter/setter` of the Proxy method is somewhat different from the `getter/setter` set by `Object.defineProperty`. Specifically:

1.  **Can intercept the entire object** `Proxy` does not need to define getter/setter for each property individually. It can be handled uniformly directly in `get/set`.
2.  **Supports dynamic properties** Adding/deleting properties can be intercepted and listened to. So extra APIs like `Vue.set` are no longer needed.
3.  **Native array support** Accessing array indices, `length`, or executing methods like `push` will trigger the `set` interceptor. Therefore, there's no need to manually rewrite the array prototype for extra array operations.
4.  **Supports more operations** `Object.defineProperty` can only intercept property read/write. But `Proxy` can intercept 13 operations: `get`, `set`, `deleteProperty`, etc. This makes the reactivity system more flexible (e.g., `for...in` traversal can also trigger dependency collection).

Proxy can also achieve **better performance**. When initializing an object, there's no need to deeply traverse all properties; it only triggers `get` when actually accessed, resulting in better performance.

Next, let's use the Proxy mechanism to implement a **real DOM two-way binding version** that can bind object properties to `<input>` elements, using the Proxy mechanism to implement a simple two-way binding mechanism.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Proxy Two-Way Binding Example</title>
</head>
<body>
  <input id="input" type="text" />
  <p id="display"></p>

  <script>
    // Data object
    const data = { message: 'Hello Proxy' };

    // Get DOM elements
    const inputEl = document.getElementById('input');
    const displayEl = document.getElementById('display');

    // Display initial value
    inputEl.value = data.message;
    displayEl.textContent = data.message;

    // Create Proxy, implement Data -> View
    const proxyData = new Proxy(data, {
      set(target, prop, value) {
        target[prop] = value;

        // Update view when data changes
        if (prop === 'message') {
          inputEl.value = value;
          displayEl.textContent = value;
          console.log(`View updated: ${prop} = ${value}`);
        }

        return true;
      },
      get(target, prop) {
        return target[prop];
      }
    });

    // View -> Data binding
    inputEl.addEventListener('input', (e) => {
      proxyData.message = e.target.value; // Automatically update data, trigger Proxy
      console.log(`Input changed: ${e.target.value}`);
    });

    // Test
    setTimeout(() => {
      proxyData.message = 'Hello Two-Way Binding!';
    }, 2000);
  </script>
</body>
</html>
```

In the above code,

1.  When the data changes, automatically update the `<input>` and `<p>` display.
2.  When the input box changes, automatically update the data object.
3.  The `set` interceptor of `Proxy` is responsible for Data -> View, the `input` event is responsible for View -> Data.


Two-ways binding's minimal implementations and simple examples with JavaScript in frontend.

Two-Ways Binding in Frontend Implementation

Let us implement rendering markdown in React and we'll embark on fundamental conceptions of Markdown compiling procession with usages and examples for unified plugins.

How to Render Markdown Document in React


对于欧洲等基于字母文字的地区来讲，字体优化是一件很简单的事情，字体大小一般不超过 1MB。**但是对于亚洲尤其是东亚中国港澳台及日韩来讲，字体尺寸是一件非常令人头疼的问题。在前端项目中，字体文件可能动辄上几个单位的兆字节甚至更多。**

举个例子，以西班牙语的 `Cantina Fresca` 字体来讲，TTF 格式的字体大小仅为 300KB，并且打包成 WOFF2 格式后可以优化到 200KB 的大小，对于一个前端页面来讲，甚至还没有一张位图的体积大，加载字体的速度和时间均在可接受的范围内，并不是问题。

但是，对汉字不尽如此。汉字的基本单位 —— 偏旁部首不像字母文字一样可以随意拼接组合，而是必须以字为单位具体设计。根据中国的汉字分类法，一类汉字和二类汉字数量中常用的汉字数量大约在 4000 左右。再加上汉字的字体矢量图形也比字母文字复杂得多，所以一个包括常用汉字的字体文件大小至少在 2MB 以上，是字母字体的五到六倍。

如果字体文件太大，对于前端来讲则是很大的负担。过大的字体文件不仅会严重拖延加载速度，而且字体可能会导致页面排版布局的改变而触发浏览器重排（reflow）机制，降低渲染性能。

## 做成图片

在早期的网页，若想使用艺术字体，那么其中一种方法，就是用专业的设计软件如 PhotoShop 把字体用在图片素材上，或者生成背景透明的文字图片再用到网页上。这种办法一般只用于展示页、落地页。

![比如故宫博物院网站首页，把艺术字体用在落地页图片上](https://image-assets.dreams.plus/20240323103632.webp)

需要用什么字体，提前设计做成图片上，虽然有效，但如今看来这是一种笨办法。因为落地页是需求变化频率非常高的场合，如果需求变更，要求修改文字内容，亦或者是调整大小、颜色，那么还需要重头开始制作字体图片，从 UI 组到前端就必须重新干活，效率低下。

如果可以，我们换一种改进方法：制作字库。提前把所有的字符都抽出来做成矢量图片，需要的时候可以从字库中选取指定的图片即可。现在这种方法还常见于某些网站的落地页、展示页。

## 子集化

做成图片的方式效率太低，那么有没有办法改进办法呢？其中一个方法就是字体子集化（Subsetize）。字体文件是按照编码来给每个文字分别储存字形的。

根据中国大陆的文字分类工作方案，字表共收字 8105 个，其中一级字表（常用字集）3500 个，二级字表 3000 个。而一类字和二类字中有 4000 左右的常用汉字，就可以覆盖 90% 以上的文献资料。对于商业网站来讲，这些字量完全够用了。

而大多数字体也通常会给生僻字编码。像[康熙字典体](https://www.kangxizidian.com/index.php)具有很高的美学价值，完整版收录了 10 万左右的汉字，体积大小也达到了惊人的 70 MB，而其中 99% 以上都是生僻字。这些生僻字我们不需要，把它裁剪去就行了。在 Github 上有很多相关的工具，如 [FontSmaller](https://fontsmaller.github.io/)，这是一个在线子集化工具，还有[Fontmin](https://github.com/ecomfe/fontmin) 等。[我自己也收集总结了一些常用的汉字、符号等](https://gist.github.com/PrinOrange/20b6cf068e750b84b1236a52449f43f9)，可以用于字体子集化时挑选出指定的目标字体，用于参考。

被裁减后的康熙字典体体积可以缩减成 5MB。

对于静态生成式网页也可以更激进一点：由于生成的文字内容是相对固定的，那么每次生成网页时，可以先读取出网页上都有哪些字符，然后再从字体中挑选对应字符的字体，然后生成字体的子集。

例如 PHP 的 [php-font-lib](https://github.com/dompdf/php-font-lib) 库、Webpack 构建系统的插件[Fontmin-Webpack](https://github.com/patrickhulce/fontmin-webpack)。但是这样的方案适合静态生成式网页，对于动态网页则灵活性非常差，也不能很好处理用户输入的问题。

## Web Open Font Format

子集化的方案虽然能裁剪去很多不必要的字符，但是优化空间仍然有限。而对于 TTF，OTF 这类字体格式，那么能否寻找一种方式，能大限度地压缩字体文件大小？

后来，Mozilla 与 Type Supply、LettError 及其他组织于 2009 年协同开发了一种新的网页字体格式 WOFF（Web Open Font Format，Web 开放字体格式）。它使用了与 TrueType、OpenType、Open Font 所采用的 sfnt 结构类似的压缩算法。

WOFF 本质上是包含了基于 sfnt 的字体（如 TrueType、OpenType 或开放字体格式），且这些字体均经过 WOFF 的编码工具压缩，以便嵌入网页中。这个字体格式使用 zlib 压缩，文件大小一般比 TTF 小 40%。

后来对 WOFF 格式上再做一些改进，又开发了 WOFF2 格式。WOFF 2 标准在 WOFF1 的基础上，进一步优化了体积压缩，带宽需求更少，同时可以在移动设备上快速解压。

与 WOFF 1.0 中使用的 Flate 压缩相比，WOFF 2.0 是使用 Brotli 方法进行的压缩，压缩率更高，所以文件体积更小。

[在 Github 上也提供了字体转换为 WOFF 的相关工具](https://github.com/odemiral/WOFF2sfnt-sfnt2WOFF)。而且很多的专业字体转换网站如[Convert.io](https://cloudconvert.com/ttf-to-WOFF2)都提供字体转换功能

借助这种优化方案，我们就可以把子集化的字体在此基础上，继续优化到原大小的 40% 左右。例如我这个博客，正文使用的是思源屏显臻宋，由原来的 13.8MB 的 TTF 文件优化到现在的 2.5MB 左右。

但尽管如此，浏览器在加载超过 1MB 的字体时，性能非常差用 lighthouse 测评得分也很难超过 60。

## Font Spilt

根据统计，打开一个网站时，**用户能接受的加载时间为 7 秒左右。** 超过这个时间，用户就会丧失兴趣。以现代的网络条件下，不包括浏览器渲染过程，以带宽速度 0.5MBPS 下，想要在 7 秒内加载完一个网页，就意味着加载网站数据，包括静态资源、网页内容等大小一般在 2-3MB 左右。

但是中文字体再怎么优化也很难优化成 1MB 以下，中文字体大小在加载数据中仍然是个大头。这显然在用户体验上也不符合要求。

那么还有没有别的方案呢？或许，我们可以让字体按需加载。思路是：把一个完整的字体按照字符范围，拆分成十几个甚至几十上百个小字体。加载网页时，在网页上找出有哪些字符，然后再加载对应收录范围的小字体文件。

![如图，使用的是思源宋体，字体分包后分成了 60 左右的小字体，但是加载时只按需用了其中的 11 个。](https://image-assets.dreams.plus/20240323122837.webp)

这也是 [Google Fonts](https://fonts.google.com/) 的优化方案。

由此一来，就有望把字体加载大小降到 1MB 以下。这项方案需要 CSS 的支持。在 CSS 中有一个非常重要的规则：[unicode-range](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/unicode-range)。

> The unicode-range CSS descriptor sets the specific range of characters to be used from a font defined using the @font-face at-rule and made available for use on the current page. If the page doesn't use any character in this range, the font is not downloaded; if it uses at least one, the whole font is downloaded.

简单来说，就是在使用 `@font-face` 定义字体时，它允许你指定 `unicode-range` 来标注应用字体的文字 Unicode 编码范围。

```css
@font-face {
  font-family: "source-serif";
  src: url("./source-serif.woff2") format("woff2");
  unicode-range: U+e240-e34f;
}
```

例如以上代码，这一行指定了应使用此字体的 Unicode 范围。在这个例子中，它只会对从 U+E240 到 U+E34F 的范围这一区间内的文字应用字体。假如文字不在 U+e240-e34f 这个编码范围内，那么就不会加载 source-serif 这个字体。

Google Font 就遵循了这个思路，通常针对中文字体把文字编码拆分成 100kb 左右的大量小字体文件，然后再生成对应的 CSS 规则代码，实现字体按需加载。

有了这个 CSS 特征，那么我们就可以很好地进一步优化了。首先第一步就是 Font-spilt，为字符范围编码，生成大量的、体积小的子字体，第二步是为编码范围和字体碎片生成指定的 CSS 规则文件。

这样就可以把每次加载字体的数据控制到 1MB，甚至 500KB 以下。就大大节省了加载数据量。

![优化前](https://image-assets.dreams.plus/20240323123739.webp)

![优化后](https://image-assets.dreams.plus/20240323123824.webp)

[在 Github 上已有对这类方案的成熟实现](https://github.com/Konghayao/cn-font-split)，并且提供了[在线的 Font-Spilt 工具](https://chinese-font.netlify.app/online-split/)，进行字体分包。

在此之前，开源界对中文字体的优化方案很少，感谢 [@江夏尧](https://github.com/KonghaYao) 的 [中文网字计划](https://chinese-font.netlify.app/)，提供了这个优秀的项目。

![](https://image-assets.dreams.plus/20240323124509.webp)

不尽如此，中文网字计划还托管了很好看的中文字体，可以开箱使用。[也欢迎各位为这个项目提供更好看的中文字体。](https://github.com/KonghaYao/chinese-free-web-font-storage)


对于欧洲等基于字母文字的地区，字体优化简单，大小通常不超过 1MB。但对于东亚国家，字体尺寸是一个头疼的问题，可能会达到数兆字节甚至更多。

汉字的前端字体体积优化方案


**Because browsers have inherent defects in DOM manipulation**. First of all, we need to know how the browser renders the code into a view after receiving the web page.

Different processes of a browser have different divisions of labor, among which the rendering process is responsible for rendering the page. \*\*
Taking Chromium-based browsers as an example, the workflow is roughly like this:

- Parse HTML and construct **DOM Tree**
- Parsing CSS, constructing **CSSOM**
- Generate the final **Render Tree** from the comprehensive construction of `DOM` and `CSSOM`
- Calculate layout parameters for Render tree\*\*
- The final Render tree, using the browser's rendering engine for **drawing**

It can be known that the process from HTML/CSS to Render Tree has gone through a very complicated process. Among them, the processes that take the longest time are the fourth and fifth steps: calculating layout parameters and drawing. When a DOM is added or removed from the page, the browser needs to start from scratch, construct the Render Tree, recalculate the layout and render the modified DOM tree again, which is a very resource-intensive and computationally intensive task.

The above is one reason, but there is another more important reason is that JavaScript accesses the information of DOM objects in the browser, and it also needs to build a bridge between JS and DOM, which needs to rely on the underlying implementation of the browser, which is also a very costly process. resource process. On the other hand, the resources of the main process are limited, and the JavaScript interpretation thread and rendering thread are mutually blocked. Manipulating the DOM requires JavaScript. Therefore, when JavaScript is executed, the view update will be blocked, and the rendering effect will be displayed externally, which will reduce the user experience.

Therefore, in order to reduce the adverse impact of manipulating the DOM on performance, there are two ideas:

- Reduce the number of visits to the DOM.
- Reduce the number of times to create and delete DOM objects, and reuse the existing DOM as much as possible.

For the first idea, the overhead of js accessing the DOM in the browser is very high, so you can **use virtual DOM** to solve this problem. Virtual DOM is a structure of simulated DOM that JS self-maintains. It stores the abstract information of real DOM, which can save the overhead of accessing real DOM. Changing the access to real DOM to virtual DOM, and changing the operation of real DOM to virtual DOM can reduce a lot of overhead.

For the second case, use the Diff algorithm to compare the information before and after the update on the virtual DOM. The Diff algorithm is essentially a tree traversal to find out the changed tree nodes. Therefore, after a bunch of operations on the virtual DOM, and then comparing the differences between the two trees before and after the operation, the original nodes can also be reused to a large extent to reduce overhead.

Take the Todo List as an example, use the `<li>` tag to store the item content. Now if you want to delete an item and add another item, then in the native method it is:

- Get the corresponding `<li>` element
- Remove the `<li>` element
- New `<li>` element
- Fill data and insert into current DOM tree, trigger Relayout and Repaint

But with Diff + Virtual DOM, it is:

- Store all `<li>` in a JS object in advance to construct a virtual DOM
- Remove `<li>` in virtual DOM
- Add `<li>` in the virtual DOM to get a new virtual DOM
- Using the Diff algorithm to compare the two new and old virtual DOMs, it is found that the number of DOMs has not changed, and the existing DOM objects can be reused, and there is no need to delete or create DOMs, just change the data.

Now front-end frameworks such as React\Vue use the Diff algorithm and virtual DOM to reduce the unnecessary performance overhead of operating and accessing DOM, roughly following the above ideas, and making up for the performance defects of front-end DOM operations.


Because browsers have inherent defects in DOM manipulation. First of all, we need to know how the browser renders the code into a view after receiving the web page.

Why Are Node Operations Rarely Used in Frontend?


### **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.

Closure in JavaScript


**I have a suggestion: When you are entangled in whether to use a certain technology, first check what level the technology solves and what problems, and then examine whether you need to solve such problems. Can save unnecessary entanglement.**

So what problem does WebSocket solve? The session management in the traditional HTTP protocol is not perfect. The client must actively initiate a Request request before the server can deliver messages to the client.

If the client submits a time-consuming task to the server, how does the server send a message to the client after it is done? In other words, in some scenarios, the server must ensure that the client is online. The solution is AJAX polling or alive detection. The client sets a timer, and every once in a while the client will initiate an AJAX request to the server, asking whether the server has completed the task, or actively telling the server "I am still online", so as to obtain the data returned by the server in time.

AJAX polling is still useful if there are fewer clients and the server performance is strong enough, but if there are more clients, what if the server has to accept requests from tens of thousands of clients? Not to mention taking up bandwidth, can the server withstand these pressures? If the real-time requirements are high, it means that resources are updated frequently and the amount of data transmitted is large, such as games and web conferences, and the method of conveying messages through AJAX polling cannot be used.

**WebSocket solves the two problems mentioned above: it makes up for the defect that the server cannot actively contact the client, and jointly solves the pressure brought by the traditional one-way communication on the server. Another is to solve the problem of real-time communication**

The client and the server only need to complete a handshake, and a persistent connection can be created directly between the two, and two-way data transmission can be performed. In this way, even if there is no explicit request from the client, the server can send information to the client, realizing reverse communication.

Although WebSocket also has a certain performance consumption, it is still very cost-effective compared to the consumption of large-scale AJAX polling.

If your business scenario needs to solve the above two problems, then it is recommended to use it, otherwise it is unnecessary, depending on your understanding of the business.


Should Put All Requests in a Websocket Connection?


## React.memo

React.memo is a **component level** cache API in React, which can temporarily store rendered components, and when necessary, decide whether to update the rendering or obtain it directly from the cache to avoid unnecessary component rendering.

And its' usage:

```javascript
const MyMemoedComponent = React.memo(
  function MyComponent(props) {
    /* render with props */
  },
  function compare(prevProps, currentProps) {
    /* logics for comparing the prevProps and nextProps */
  },
);
```

It returns a Memorized function component.

When used, it accepts two parameters: the first is the target component, which is the definition of the component that needs to be optimized.
The second is the comparison function `compare`, which receives the currentProps passed in for each round of rendering and the prevProps passed in for the last rendering.

However, due to the immutable feature in the React function component, the component will be rendered according to its Props. However, when the same or equivalent Props are used multiple times during rendering, performance will be wasted.

Users can write their own logic to determine whether the two incoming props are logically equivalent. The `compare` function is expected to return a boolean value. If it returns `true`, it means that the props passed in twice are equivalent. Then during the current round of rendering, the last component will be directly taken out of the cache without re-rendering the component.

For example, when it is necessary to render a personal resume information, if the personal information on the resume remains unchanged, then there is no need to re-render. Can be used like this:

```javascript
const MyMemoedProfile = React.memo(
  function Profile({ name, sex, age, job }) {
    return (
      <div>
        <h2>{`Your Name: ${name}`}</h2>
        <ul>
          <li>{`sex: ${sex}`}</li>
          <li>{`age: ${age}`}</li>
          <li>{`job: ${job}`}</li>
        </ul>
      </div>
    );
  },
  function compare(prevProps, currentProps) {
    return (
      prevProps.name === currentProps.name &&
      prevProps.sex === currentProps.sex &&
      prevProps.age === currentProps.age &&
      prevProps.job === currentProps.job
    );
  },
);
```

## useMemo

The `React.memo` mentioned above is the optimization of the component level, **then useMemo is the optimization of the internal calculation logic of the component.**

JavaScript is not suitable for intensive calculations. But if we have calculation-intensive logic inside the component, every time the component is rendered, the calculation must be done again, which is also unacceptable for performance. Therefore, useMemo can temporarily store the intensive calculation results of each time, and then decide whether to repeat the calculation according to the judgment.

The specific usage is as follows:

```javascript
const memoizedValue = useMemo(() => doSomeComputeExpensiveWork(a, b, ...), [a, b, ...]);
```

Unlike React.memo, its first parameter is a function that returns a computationally intensive function. It accepts dependencies instead of comparison functions as its second argument. Dependencies will be compared (shallow comparison here) every time a value is fetched. If the dependencies are the same, the last rendering result will be reused instead of recalculated. If the dependencies are different, call the computationally intensive function returned by the first argument.

For example, we want to design a component that displays the Fibonacci sequence: input the number of items `n`, and return the Fibonacci number of the `n`th item.

```javascript
function FibonacciNumber({ n }) {
  const target_value = useMemo(
    () =>
      function calc(n) {
        let arr = [];
        if (n < 1) return arr;
        let one = 1,
          two = 0,
          three = 0;
        for (let i = 1; i <= n; i++) {
          three = one + two;
          arr.push(three);
          one = two;
          two = three;
        }
        return arr;
      },
    [n],
  );
  return <div>{`The ${n} th's fibonacci number is : ${target_value}`}</div>;
}
```

In this way, no matter how many rounds the component renders, as long as the dependency `n` remains unchanged, the previously calculated Fibonacci numbers will be obtained from the cache instead of recalculated. If a new `n` is obtained, the `calc` function returned by the first parameter will be used again to calculate the new value with `n` as the parameter.

If the dependency is empty, the data is always fetched from the cache.

## useCallback

useMemo has a problem: the function in the first argument must return a computationally intensive function. If the first parameter is directly set to a calculation-intensive function, it will be simplified a lot, as long as the calculation-intensive function does not need to be changed.

useCallback can be regarded as the equivalent grammatical sugar of useMemo, and there is the following conversion relationship between them:

`useCallback(fn, deps)` is equivalent to `useMemo(() => fn, deps)`.

Like useMemo, if the dependency is empty, the data is always fetched from the cache.

## useEvent

Try the following code:

```javascript
const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const handleClick = () => {
    console.log(counter);
    setCounter((counter) => counter + 1);
  };

  return <div onClick={handleClick}>click to add counter counter: {counter}</div>;
};
```

There seems to be no problem with this component, but if you think about it carefully, a new `handlerClick` event function will be recreated every time it is rendered and then passed to the button. So if the component is rendered many times, the handlers established in history will accumulate more and more.

In order to solve this problem, we put a layer of useCallback to cache the event forever, and always get data from the cache in each round of rendering:

```javascript
const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const handleClick = useCallback(() => {
    console.log(counter);
    setCounter((counter) => counter + 1);
  }, []);

  return <div onClick={handleClick}>click to add counter counter: {counter}</div>;
};
```

But this triggers React's closure trap. The `counter` in the function in the first parameter is always the value when the component is first created, that is `0`.

So useEvent solves the problem:

```javascript
const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const handleClick = useEvent(() => {
    console.log(counter);
    setCounter((counter) => counter + 1);
  });

  return <div onClick={handleClick}>click to add counter counter: {counter}</div>;
};
```

But it is still an experimental feature today and not recommended for production use.


MY BLOG

FRONTEND