ALGORITHM

COMPUTATION

CRYPTOGRAPHY

FRONTEND

GAME-THEORY

INVESTMENT

JS&TS

LINUX

MATHEMATICS

NODE

PROJECT-PRACTICE

REACT

THOUGHTS

古文整理

文史哲艺


## Theorem

Let $n, p \in \mathbb{Z}_{>0}$ be (strictly) positive integers.

Then:

$$
\sum_{k = 1}^n k^p = \frac{1}{p + 1} \sum_{i = 0}^p (-1)^i \binom{p + 1}{i} B_i n^{p + 1 - i} \\
= \frac{n^{p + 1}}{p + 1} - \frac{B_1 \cdot n^p}{1!} + \frac{B_2 \cdot p \cdot n^{p - 1}}{2!} + \frac{B_4 \cdot p \cdot (p - 1) \cdot (p - 2) \cdot n^{p - 3}}{4!} + \cdots
$$

where:

- $B_i$ denotes the $i$th Bernoulli number.

## Proof

Let $x \ge 0$.

$$
\sum_{k = 0}^{n - 1} e^{k x} = \sum_{k = 0}^{n - 1} \sum_{p = 0}^\infty \frac{(k x)^p}{p!}
$$

$$
= \sum_{p = 0}^\infty \left(\sum_{k = 0}^{n - 1} k^p\right) \frac{x^p}{p!}
$$

We also have:

$$
\sum_{k = 0}^{n - 1} e^{k x} = \frac{1 - e^{n x}}{1 - e^x}
$$

Sum of Geometric Sequence

$$
= \frac{e^{n x} - 1}{x} \frac{x}{e^x - 1}
$$

multiplying numerator and denominator by $x$

$$
= \frac{1}{x} \left(\sum_{p = 0}^\infty \frac{(n x)^p}{p!} - 1\right) \sum_{p = 0}^\infty \frac{B_p x^p}{p!}
$$

Definition of _Bernoulli Numbers_ and _Power Series Expansion_ for Exponential Function

$$
= \frac{1}{x} \left(\sum_{p = 1}^\infty \frac{(n x)^p}{p!}\right) \sum_{p = 0}^\infty \frac{B_p x^p}{p!}
$$

Factorial of $0$ and Zeroth Power

$$
= \frac{1}{x} \left(\sum_{p = 0}^\infty \frac{(n x)^{p + 1}}{(p + 1)!}\right) \sum_{p = 0}^\infty \frac{B_p x^p}{p!}
$$

Translation of Index Variable of Summation

$$
= \sum_{p = 0}^\infty \frac{n^{p + 1} x^p}{(p + 1)!} \sum_{p = 0}^\infty \frac{B_p x^p}{p!}
$$

Power of Product

$$
= \sum_{p = 0}^\infty \sum_{i = 0}^p \frac{n^{p + 1 - i} x^{p - i}}{(p + 1 - i)! i!} B_i n^{p + 1 - i} x^p
$$

Definition of Cauchy Product

$$
= \sum_{p = 0}^\infty \left(\frac{1}{p + 1} \sum_{i = 0}^p \binom{p + 1}{i} B_i n^{p + 1 - i}\right) \frac{x^p}{p!}
$$

multiplying by $1$ and Product of Powers

$$
\sum_{k = 0}^{n - 1} k^p = \frac{1}{p + 1} \sum_{i = 0}^p \binom{p + 1}{i} B_i n^{p + 1 - i}
$$

Definition of Binomial Coefficient

$$
\implies \sum_{k = 1}^n k^p = \frac{1}{p + 1} \sum_{i = 0}^p (-1)^i \binom{p + 1}{i} B_i n^{p + 1 - i}
$$

Equating coefficients:

$$
\sum_{k = 0}^{n - 1} k^p = \frac{1}{p + 1} \sum_{i = 0}^p \binom{p + 1}{i} B_i n^{p + 1 - i}
$$

$$
\implies \sum_{k = 0}^{n - 1} k^p + n^p = \frac{1}{p + 1} \sum_{i = 0}^p \binom{p + 1}{i} B_i n^{p + 1 - i} + \left(\frac{1}{p + 1} \binom{p + 1}{1} n^p\right)
$$

adding $n^{p}$ to both sides and Binomial Coefficient with One

$$
\implies \sum_{k = 1}^n k^p = \frac{1}{p + 1} \sum_{i = 0}^p (-1)^i \binom{p + 1}{i} B_i n^{p + 1 - i}
$$

as $B_{1}=-\frac{1}{2}$ and Odd Bernoulli Numbers Vanish

**Q.E.D.**


Faulhaber's Formula, which provides a method to compute the sum of the p-th powers of the first n positive integers.

Proof of Faulhaber's Formula


## Catalan Numbers

Catalan numbers $H_n$ can be applied to the following problems:

1. There are $2n$ people queuing up to enter a theater. The entrance fee is 5 yuan. Among them, only $n$ people have a 5 yuan bill, while the other $n$ people only have a 10 yuan bill. The theater has no other bills. How many ways are there to ensure that whenever a person with a 10 yuan bill buys a ticket, the ticket office has a 5 yuan bill for change?
2. There is a grid of size $n\times n$ with the lower left corner at $(0, 0)$ and the upper right corner at $(n, n)$. Starting from the lower left corner, you can only move one unit to the right or up each time, without going above the diagonal line $y=x$. How many possible paths are there to reach the upper right corner without crossing the line $y=x$?
3. Choose $2n$ points on a circle and connect these points pairwise to obtain $n$ line segments. How many ways are there to ensure that the $n$ line segments obtained do not intersect?
4. Without intersecting diagonals, how many ways are there to divide a convex polygon area into triangular regions?
5. If the stack (infinite) has a push sequence of $1,2,3, \cdots ,n$, how many different pop sequences are there?
6. How many different binary trees can be constructed with $n$ nodes?
7. Given $2n$ numbers consisting of $n$ $+1$s and $n$ $-1$s, denoted as $a_1,a_2, \cdots ,a_{2n}$, such that the partial sum satisfies $a_1+a_2+ \cdots +a_k \geq 0~(k=1,2,3, \cdots ,2n)$, how many sequences satisfy this condition?

The corresponding sequence is:

| $H_0$ | $H_1$ | $H_2$ | $H_3$ | $H_4$ | $H_5$ | $H_6$ | ... |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: | :-: |
|   1   |   1   |   2   |   5   |  14   |  42   |  132  | ... |

## Recurrence Relation

The solution to this recurrence relation is:

$$
H_n = \frac{\binom{2n}{n}}{n+1}(n \geq 2, n \in \mathbf{N_{+}})
$$

Common formulas for Catalan numbers are:

$$
H_n = \begin{cases}
    \sum_{i=1}^{n} H_{i-1} H_{n-i} & n \geq 2, n \in \mathbf{N_{+}}\\
    1 & n = 0, 1
\end{cases}
$$

$$
H_n = \frac{H_{n-1} (4n-2)}{n+1}
$$

$$
H_n = \binom{2n}{n} - \binom{2n}{n-1}
$$

> A common application: for a stack, the push sequence is $1,2, \ldots ,n$, find the total number of possible pop sequences.

```cpp
#include <iostream>
using namespace std;
int n;
long long f[25];

int main() {
  f[0] = 1;
  cin >> n;
  for (int i = 1; i <= n; i++) f[i] = f[i - 1] * (4 * i - 2) / (i + 1);
  // Here, formula 2 is used
  cout << f[n] << endl;
  return 0;
}
```

## Closed Form

The recurrence relation of Catalan numbers is

$$
H_n=\sum_{i=0}^{n-1}H_{i}H_{n-i-1} \quad (n\ge 2)
$$

where $H_0=1$ and $H_1=1$. Let its ordinary generating function be $H(x)$.

We find that the recurrence relation of Catalan numbers is similar to the form of convolution. Therefore, we construct an equation about $H(x)$ using convolution:

$$
\begin{aligned}
H(x)&=\sum_{n\ge 0}H_nx^n\\
&=1+\sum_{n\ge 1}\sum_{i=0}^{n-1}H_ix^iH_{n-i-1}x^{n-i-1}x\\
&=1+x\sum_{i\ge 0}H_{i}x^i\sum_{n\ge 0}H_{n}x^{n}\\
&=1+xH^2(x)
\end{aligned}
$$

Solving this equation, we get

$$
H(x)=\frac{1\pm \sqrt{1-4x}}{2x}
$$

Now, we have a question: which root should we take? Rationalizing the numerator, we get

$$
H(x)=\frac{2}{1\mp \sqrt{1-4x}}
$$

Substituting $x=0$, we obtain the constant term of $H(x)$, which is $H_0$. When $H(x)=\dfrac{2}{1+\sqrt{1-4x}}$, we have $H(0)=1$, satisfying the requirement. The other root leads to the denominator being $0$ (non-convergence), so it is discarded.

Therefore, we obtain the closed form of the generating function of Catalan numbers:

$$
H(x)=\frac{1- \sqrt{1-4x}}{2x}
$$

Next, we need to expand it. But note that its denominator is not in the form of a polynomial like the Fibonacci sequence, so it is not convenient to use the expansion form of geometric sequences. Here we need to use Newton's binomial theorem. Let's first expand $\sqrt{1-4x}$:

$$
\begin{aligned}
(1-4x)^{\frac{1}{2}}
&=\sum_{n\ge 0}\binom{\frac{1}{2}}{n}(-4x)^n\\
&=1+\sum_{n\ge 1}\frac{\left(\frac{1}{2}\right)^{\underline{n}}}{n!}(-4x)^n
\end{aligned} \tag{1}
$$

Note that

$$
\begin{aligned}
\left(\frac{1}{2}\right)^{\underline{n}}
&=\frac{1}{2}\frac{-1}{2}\frac{-3}{2}\cdots\frac{-(2n-3)}{2}\\
&=\frac{(-1)^{n-1}(2n-3

)!!}{2^n}\\
&=\frac{(-1)^{n-1}(2n-2)!}{2^n(2n-2)!!}\\
&=\frac{(-1)^{n-1}(2n-2)!}{2^{2n-1}(n-1)!}
\end{aligned}
$$

Here, we use the simplification technique of double factorials. Then, substitute into $(1)$, we get

$$
\begin{aligned}
(1-4x)^{\frac{1}{2}}
&=1+\sum_{n\ge 1}\frac{(-1)^{n-1}(2n-2)!}{2^{2n-1}(n-1)!n!}(-4x)^n\\
&=1-\sum_{n\ge 1}\frac{(2n-2)!}{(n-1)!n!}2x^n\\
&=1-\sum_{n\ge 1}\binom{2n-1}{n}\frac{1}{(2n-1)}2x^n
\end{aligned}
$$

Substitute back into the original expression, we get

$$
\begin{aligned}
H(x)&=\frac{1- \sqrt{1-4x}}{2x}\\
&=\frac{1}{2x}\sum_{n\ge 1}\binom{2n-1}{n}\frac{1}{(2n-1)}2x^n\\
&=\sum_{n\ge 1}\binom{2n-1}{n}\frac{1}{(2n-1)}x^{n-1}\\
&=\sum_{n\ge 0}\binom{2n+1}{n+1}\frac{1}{(2n+1)}x^{n}\\
&=\sum_{n\ge 0}\binom{2n}{n}\frac{1}{n+1}x^{n}\\
\end{aligned}
$$

Thus, we obtain the general formula for Catalan numbers.

## Path Counting Problem

Non-decreasing paths refer to paths that can only move upwards or to the right.

1. The number of non-decreasing paths from $(0,0)$ to $(m,n)$ is equal to the number of permutations of $m$ $x$ and $n$ $y$, i.e., $\dbinom{n + m}{m}$.

2. The number of non-decreasing paths from $(0,0)$ to $(n,n)$ that do not touch the line $y=x$ except at endpoints:

   First, consider the paths below the line $y=x$, which all start from $(0, 0)$, pass through $(1, 0)$ and $(n, n-1)$, and reach $(n,n)$. This can be seen as the number of non-decreasing paths from $(1,0)$ to $(n,n-1)$ without touching $y=x$.

   All non-decreasing paths total $\dbinom{2n-2}{n-1}$. For any path that touches $y=x$, we can symmetrically transform the part from the point where it leaves this line to $(1,0)$, obtaining a non-decreasing path from $(0,1)$ to $(n,n-1)$. The reverse is also true. Hence, the number of non-decreasing paths below $y=x$ is $\dbinom{2n-2}{n-1} - \dbinom{2n-2}{n}$. Due to symmetry, the answer is $2\dbinom{2n-2}{n-1} - 2\dbinom{2n-2}{n}$.

3. The number of non-decreasing paths from $(0,0)$ to $(n,n)$ that do not cross the line $y=x$: Similarly, we can obtain $\dfrac{2}{n+1}\dbinom{2n}{n}$ using similar methods.

> NOTE: This article is rewritten by [OI WIKI](https://oi-wiki.org/math/combinatorics/catalan/).


The article discusses Catalan numbers, a sequence used in combinatorial problems. It covers their recurrence relation, closed form, and applications in path counting. It provides insights into problem-solving using Catalan numbers.

The Catalan Series


## Symbols and definitions

1. **Big O notation ($O$)**: If $\exists{c, n_{0}} \in \mathbb{R}^{+}$, such that $\forall{n} > n_0$, $f(n) \leq cg(n)$, then $f(n) = O(g(n))$.
2. **Small o symbol ($o$)**: If $\forall{c} > 0$, $\exists{n_0}$, such that $\forall{n} > n_0$, $f(n) < cg (n)$, then $f(n) = o(g(n))$.
3. **Big Omega symbol ($Ω$)**: If $\exists{c, n_{0}} \in \mathbb{R}^{+}$, such that $\forall{n} > n_0$, $ f(n) \geq cg(n)$, then $f(n) = \Omega(g(n))$.
4. **Small omega symbol ($ω$)**: If $\forall{c} > 0$, $\exists{n_0}$, such that $\forall{n} > n_0$, $f(n) > cg (n)$, then $f(n) = \omega(g(n))$.
5. **Theta symbol ($θ$)**: If $\exists{c_1, c_2, n_0} \in \mathbb{R}^{+}$, such that $\forall{n} > n_0$, $c_1g( n) \leq f(n) \leq c_2g(n)$, then $f(n) = \Theta(g(n))$. It can be understood that when the complexity of the upper bound and the lower bound both increase by the same amount, then this complexity is also called a compact bound.

These notations describe the asymptotic behavior of algorithms' time complexity, aiding in understanding their performance characteristics.

| Notation | Meaning           | Intuition                |
| -------- | ----------------- | ------------------------ |
| $\Theta$ | Tight Bound       | Equivalent to "="        |
| $O$      | Upper Bound       | Less than or equal to    |
| $o$      | Loose Upper Bound | Less than                |
| $\Omega$ | Lower Bound       | Greater than or equal to |
| $\omega$ | Loose Lower Bound | Greater than             |

## Average, Best, Worst Cases

Time complexity is generally used to compare different algorithms, such as bubble sort, insertion sort, and heap sort. However, for the same algorithm, depending on the input, we can also consider average, best, and worst case time complexities. For example, the time complexity of a binary search tree varies between a singly linked list and a balanced tree.

**Average Time Complexity**: A measure of the weighted average of an algorithm's running time over all possible input cases. Let $T(n)$ be the running time of the algorithm for an input size of $n$. The average time complexity $\bar{T}(n)$ is defined as

$$
\bar{T}(n) = \sum_{i=1}^{k} p_i \cdot T_i(n)
$$

where $T_i(n)$ is the running time for the $i$th input case, $p_i$ is the probability of the $i$th case, and $k$ is the total number of possible input cases.

**Best Case Time Complexity**: The minimum running time required by an algorithm in the most ideal scenario.

**Worst Case Time Complexity**: The maximum running time required by an algorithm in the least ideal scenario.


Give five symbolic and mathematical definitions related to time complexity.

Some Definitions for Time Complexity.


This article will introduce some commonly used classical ciphers, which have been applied in history, reflecting the wisdom of ancient people. In ancient times, with low productivity and backward computing devices, classical ciphers had a certain protective effect. However, with the improvement of computer computing power nowadays, these classical ciphers have become very vulnerable and no longer practical.

Nowadays, there are many methods for breaking these classical ciphers. When I have the opportunity later on, I will summarize some of the decryption techniques for classical ciphers.

## Caesar Cipher

When it comes to classical ciphers, one classic example is the Caesar Cipher. The Caesar Cipher is a simple substitution encryption method based on letter shifting.

Core Idea: The core idea of the Caesar Cipher is to obtain the ciphertext by shifting each letter in the plaintext by a fixed number. This number of shifts is called the offset or key.

Algorithm Steps:

1. Determine the offset, i.e., the number of shifts.
2. For encryption, shift each letter in the plaintext backward by the offset to obtain the ciphertext.
3. For decryption, shift each letter in the ciphertext forward by the offset to obtain the plaintext.

TypeScript Implementation:

```typescript
function caesarCipherEncrypt(plainText: string, shift: number): string {
  let result = "";
  for (let i = 0; i < plainText.length; i++) {
    let char = plainText[i];
    if (char.match(/[a-z]/i)) {
      let code = plainText.charCodeAt(i);
      if (code >= 65 && code <= 90) {
        char = String.fromCharCode(((code - 65 + shift) % 26) + 65);
      } else if (code >= 97 && code <= 122) {
        char = String.fromCharCode(((code - 97 + shift) % 26) + 97);
      }
    }
    result += char;
  }
  return result;
}

function caesarCipherDecrypt(cipherText: string, shift: number): string {
  return caesarCipherEncrypt(cipherText, 26 - shift);
}
```

This TypeScript implementation provides encryption and decryption functions for the Caesar Cipher. The encryption function accepts plaintext and the offset as parameters and returns ciphertext, while the decryption function accepts ciphertext and the offset as parameters and returns plaintext.

## Rail Fence Cipher

The Rail Fence Cipher is a classical substitution encryption method based on rearranging the letters in the plaintext. The core idea of the Rail Fence Cipher is to rearrange the letters in the plaintext to form a matrix with a specific number of rows, and then read the letters in the matrix in a certain order to obtain the ciphertext.

Algorithm Steps:

1. Determine the height of the rail fence, i.e., the number of rows in the matrix.
2. Write the plaintext into a matrix according to the height of the rail fence.
3. Read the letters in the matrix in a specific order to obtain the ciphertext.
4. For decryption, knowing the height of the rail fence is necessary to correctly rearrange the letters in the ciphertext to obtain the plaintext.

Idea:
The Rail Fence Cipher is a substitution encryption method based on rearranging letters. Encryption and decryption are achieved by reading the letters in the matrix in a specific order.

TypeScript Implementation:

```typescript
function railFenceCipherEncrypt(plainText: string, height: number): string {
  let rail: string[][] = new Array(height).fill(null).map(() => []);
  let directionDown = false;
  let row = 0;
  for (let char of plainText) {
    rail[row].push(char);
    if (row === 0 || row === height - 1) {
      directionDown = !directionDown;
    }
    directionDown ? row++ : row--;
  }
  let result = "";
  for (let i = 0; i < height; i++) {
    result += rail[i].join("");
  }
  return result;
}

function railFenceCipherDecrypt(cipherText: string, height: number): string {
  let rail: string[][] = new Array(height).fill(null).map(() => []);
  let directionDown = false;
  let row = 0;
  for (let char of cipherText) {
    rail[row].push("x"); // Placeholder, will be replaced later
    if (row === 0 || row === height - 1) {
      directionDown = !directionDown;
    }
    directionDown ? row++ : row--;
  }
  let index = 0;
  for (let i = 0; i < height; i++) {
    for (let j = 0; j < rail[i].length; j++) {
      if (rail[i][j] === "x") {
        rail[i][j] = cipherText[index++];
      }
    }
  }
  directionDown = false;
  row = 0;
  let result = "";
  for (let i = 0; i < cipherText.length; i++) {
    result += rail[row].shift();
    if (row === 0 || row === height - 1) {
      directionDown = !directionDown;
    }
    directionDown ? row++ : row--;
  }
  return result;
}
```

This TypeScript implementation provides encryption and decryption functions for the Rail Fence Cipher. The encryption function accepts plaintext and the height of the rail fence as parameters and returns ciphertext, while the decryption function accepts ciphertext and the height of the rail fence as parameters and returns plaintext.

## Route Cipher

The Route Cipher, also known as the Path Transposition Cipher, is a substitution encryption method based on matrix rearrangement. Its core idea is to read the characters in the matrix according to a predetermined path order to encrypt or decrypt messages. The essence of the Route Cipher is to arrange the plaintext into a matrix along a specific path and then read the characters in the matrix according to the predetermined path order to obtain the ciphertext.

Algorithm Steps:

1. Arrange the plaintext into a matrix along a specific path.
2. Read the characters in the matrix according to the predetermined path order to obtain the ciphertext.
3. For decryption, read the characters in the ciphertext according to the same path order to reconstruct the plaintext.

TypeScript Implementation:

```typescript
function routeCipherEncrypt(plainText: string, rows: number, cols: number, path: number[][]): string {
  let matrix: string[][] = new Array(rows).fill(null).map(() => new Array(cols).fill(""));
  let index = 0;
  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      if (index < plainText.length) {
        matrix[r][c] = plainText[index++];
      }
    }
  }
  let result = "";
  for (let step of path) {
    let [r, c] = step;
    result += matrix[r][c];
  }
  return result;
}

function routeCipherDecrypt(cipherText: string, rows: number, cols: number, path: number[][]): string {
  let matrix: string[][] = new Array(rows).fill(null).map(() => new Array(cols).fill(""));
  let index = 0;
  for (let step of path) {
    let [r, c] = step;
    matrix[r][c] = cipherText[index++];
  }
  let result = "";
  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      result += matrix[r][c];
    }
  }
  return result;
}
```

This TypeScript implementation provides encryption and decryption functions for the Route Cipher. The encryption function accepts plaintext, the number of rows and columns in the matrix, and the path as parameters, and returns ciphertext. The decryption function accepts ciphertext, the number of rows and columns in the matrix, and the path as parameters, and returns plaintext.

It is worth noting that:

- The Route Cipher is based on path transposition.
- It uses a matrix (usually a square matrix) to represent the plaintext, and then selects characters for encryption by following a predetermined path in the matrix.
- Encryption paths can be straight lines, curves, or any other shape, with each path representing a key.
- During decryption, knowledge of the same path is required to reverse the operation.

## Vigenère Cipher

The Vigenère Cipher is a polyalphabetic substitution cipher and is one of the most famous ciphers in classical cryptography. It encrypts plaintext using a keyword, employing the concept of multiple Caesar ciphers to achieve a more complex substitution encryption.

Core Idea:
The core idea of the Vigenère Cipher is to encrypt plaintext using a keyword (key). Each letter in the keyword corresponds to a shift number in the alphabet, forming a set of Caesar ciphers. Then, for each letter in the plaintext, a shift is performed using the corresponding shift number from the keyword to obtain the ciphertext.

Algorithm Steps:

1. Choose a keyword as the key.
2. Repeat the keyword until it matches the length of the plaintext.
3. For encryption, shift each letter in the plaintext by the corresponding letter of the keyword at the same position to obtain the ciphertext.
4. For decryption, use the same keyword to shift each letter in the ciphertext by the corresponding letter of the keyword at the same position in reverse to obtain the plaintext.

The Vigenère Cipher is a polyalphabetic substitution cipher that achieves encryption and decryption by using a keyword and the concept of multiple Caesar ciphers. Compared to a single Caesar cipher, the Vigenère Cipher provides a more complex encryption method, making decryption more difficult.

TypeScript Implementation:

```typescript
function vigenereCipherEncrypt(plainText: string, key: string): string {
  const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
  let encryptedText = "";
  key = key.toUpperCase();
  for (let i = 0, j = 0; i < plainText.length; i++) {
    const char = plainText[i].toUpperCase();
    if (alphabet.includes(char)) {
      const shift = alphabet.indexOf(key[j % key.length]);
      const charIndex = alphabet.indexOf(char);
      const encryptedIndex = (charIndex + shift) % alphabet.length;
      encryptedText += alphabet[encryptedIndex];
      j++;
    } else {
      encryptedText += char;
    }
  }
  return encryptedText;
}

function vigenereCipherDecrypt(cipherText: string, key: string): string {
  const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
  let decryptedText = "";
  key = key.toUpperCase();
  for (let i = 0, j = 0; i < cipherText.length; i++) {
    const char = cipherText[i].toUpperCase();
    if (alphabet.includes(char)) {
      const shift = alphabet.indexOf(key[j % key.length]);
      const charIndex = alphabet.indexOf(char);
      const decryptedIndex = (charIndex - shift + alphabet.length) % alphabet.length;
      decryptedText += alphabet[decryptedIndex];
      j++;
    } else {
      decryptedText += char;
    }
  }
  return decryptedText;
}

// Example usage
const plainText = "HELLO";
const key = "KEY";
const encryptedText = vigenereCipherEncrypt(plainText, key);
console.log("Encrypted Text: ", encryptedText); // Output encrypted text
const decryptedText = vigenereCipherDecrypt(encryptedText, key);
console.log("Decrypted Text: ", decryptedText); // Output decrypted text
```

In this example, the `vigenereCipherEncrypt` function encrypts plaintext, and the `vigenereCipherDecrypt` function decrypts ciphertext. These functions use a keyword to encrypt plaintext and decrypt ciphertext, employing the concept of the Vigenère Cipher.

The Vigenère Cipher has been widely used historically and still holds value in modern cryptography. While it can be cracked using modern cryptographic analysis techniques, it still provides a certain level of protection under certain conditions.

## Baconian Cipher

The Baconian cipher is an ancient cryptographic technique named after the 16th-century English philosopher, Francis Bacon. This cipher utilizes the form of letters to encrypt textual information into a series of different symbols.

In the Baconian cipher, typically two different symbols, often represented as "A" and "B" (or "a" and "b"), are used to represent different letters in the plaintext. For example, "A" might represent the letter "A" in the plaintext, while "B" might represent other letters. Through this method, textual information can be transformed into a sequence of "A" and "B" characters, thus achieving encryption.

Below are the algorithm steps for the Baconian cipher:

1. Firstly, create a Baconian cipher alphabet, which includes the mapping relationship between plaintext letters and their corresponding Baconian cipher symbols. Typically, two symbols, A and B, are used to represent letters.

2. Convert the plaintext to uppercase and remove any characters other than letters.

3. Iterate over each letter in the plaintext:
   - For each letter, find its corresponding Baconian cipher symbol in the alphabet.
   - Concatenate the found Baconian cipher symbols to form the ciphertext.

Here's a TypeScript implementation:

```typescript
class BaconCipher {
  private static baconianAlphabet: { [key: string]: string } = {
    A: "AAAAA",
    B: "AAAAB",
    C: "AAABA",
    D: "AAABB",
    E: "AABAA",
    F: "AABAB",
    G: "AABBA",
    H: "AABBB",
    I: "ABAAA",
    J: "ABAAB",
    K: "ABABA",
    L: "ABABB",
    M: "ABBAA",
    N: "ABBAB",
    O: "ABBBA",
    P: "ABBBB",
    Q: "BAAAA",
    R: "BAAAB",
    S: "BAABA",
    T: "BAABB",
    U: "BABAA",
    V: "BABAB",
    W: "BABBA",
    X: "BABBB",
    Y: "BBAAA",
    Z: "BBAAB",
  };

  public static encrypt(plaintext: string): string {
    // Convert plaintext to uppercase and remove non-alphabetic characters
    plaintext = plaintext.toUpperCase().replace(/[^A-Z]/g, "");

    let ciphertext = "";
    for (let i = 0; i < plaintext.length; i++) {
      const letter = plaintext[i];
      const baconianLetter = this.baconianAlphabet[letter];
      if (baconianLetter) {
        ciphertext += baconianLetter;
      }
    }
    return ciphertext;
  }

  public static decrypt(ciphertext: string): string {
    let plaintext = "";
    for (let i = 0; i < ciphertext.length; i += 5) {
      const chunk = ciphertext.substr(i, 5);
      const letter = this.getBaconianLetter(chunk);
      if (letter !== null) {
        plaintext += letter;
      }
    }
    return plaintext;
  }

  private static getBaconianLetter(baconianCode: string): string | null {
    for (const [key, value] of Object.entries(this.baconianAlphabet)) {
      if (value === baconianCode) {
        return key;
      }
    }
    return null; // If no matching letter found
  }
}

// Example usage:
const plaintext = "HELLO";
const ciphertext = BaconCipher.encrypt(plaintext);
console.log("Plaintext:", plaintext);
console.log("Ciphertext:", ciphertext);

const decryptedText = BaconCipher.decrypt(ciphertext);
console.log("Decrypted Text:", decryptedText);
```

This TypeScript code implements the encryption and decryption functionality of the Baconian cipher. You can pass the plaintext to the `BaconCipher.encrypt()` method for encryption or pass the ciphertext to the `BaconCipher.decrypt()` method for decryption.

## Affine Cipher

The Affine cipher is an ancient substitution cipher that combines the concepts of the Caesar cipher and linear algebra. It encrypts each letter in the plaintext by using two values called the encryption key (a) and the offset key (b).

The encryption formula for the Affine cipher is $E(x) = (ax + b) \mod m$, where:

- $x$ is the numerical representation of the plaintext letter in the alphabet (usually starting from 0, where 'a' is 0, 'b' is 1, and so on).
- $a$ and $b$ are the encryption keys.
- $m$ is the size of the alphabet (usually 26 for English).

To decrypt, the modular multiplicative inverse of the encryption key is used. The encryption key $a$ must be coprime with the alphabet size $m$ to ensure that each letter can be correctly encrypted and decrypted.

Below are the algorithm steps for the Affine cipher:

1. Choose appropriate encryption key $a$ and offset key $b$.
2. Convert each letter in the plaintext to its numerical representation $x$ in the alphabet.
3. Apply the Affine encryption formula to each numerical value $x$ to obtain the corresponding ciphertext value.
4. Convert the ciphertext numerical values back to letter representations in the alphabet.

Here's a TypeScript implementation:

```typescript
class AffineCipher {
  private static readonly alphabetSize: number = 26; // Size of the English alphabet

  public static encrypt(plaintext: string, a: number, b: number): string {
    let ciphertext = "";
    plaintext = plaintext.toUpperCase().replace(/[^A-Z]/g, ""); // Convert to uppercase and remove non-alphabetic characters
    for (let i = 0; i < plaintext.length; i++) {
      const char = plaintext[i];
      const charCode = char.charCodeAt(0) - "A".charCodeAt(0); // Convert letter to numerical value from 0 to 25
      const encryptedCharCode = (a * charCode + b) % this.alphabetSize; // Affine encryption formula
      const encryptedChar = String.fromCharCode(encryptedCharCode + "A".charCodeAt(0)); // Convert numerical value back to letter
      ciphertext += encryptedChar;
    }
    return ciphertext;
  }

  public static decrypt(ciphertext: string, a: number, b: number): string {
    let plaintext = "";
    const aInverse = this.modInverse(a, this.alphabetSize); // Calculate the modular inverse of encryption key a
    for (let i = 0; i < ciphertext.length; i++) {
      const char = ciphertext[i];
      const charCode = char.charCodeAt(0) - "A".charCodeAt(0); // Convert letter to numerical value from 0 to 25
      const decryptedCharCode = (aInverse * (charCode - b + this.alphabetSize)) % this.alphabetSize; // Affine decryption formula
      const decryptedChar = String.fromCharCode(decryptedCharCode + "A".charCodeAt(0)); // Convert numerical value back to letter
      plaintext += decryptedChar;
    }
    return plaintext;
  }

  private static modInverse(a: number, m: number): number {
    for (let i = 1; i < m; i++) {
      if ((a * i) % m === 1) {
        return i;
      }
    }
    return -1; // If no modular inverse exists, return -1
  }
}

// Example usage:
const plaintext = "HELLO";
const a = 5; // Encryption key
const b = 8; // Offset key
const ciphertext = AffineCipher.encrypt(plaintext, a, b);
console.log("Plaintext:", plaintext);
console.log("Ciphertext:", ciphertext);

const decryptedText = AffineCipher.decrypt(ciphertext, a, b);
console.log("Decrypted Text:", decryptedText);
```

This TypeScript code implements the encryption and decryption functionality of the Affine cipher. You can pass the plaintext to the `AffineCipher.encrypt()` method for encryption or pass the ciphertext to the `AffineCipher.decrypt()` method for decryption.


This article explores classical ciphers historically used. In the past, amid low productivity and primitive computing, these ciphers offered protection.

Some Classical Ciphers and Implementations


I came across a question on Zhihu, which goes like this: The person wrote a piece of code to control login, and the logic of the program is roughly as follows in Java:

```java
public boolean handleLogin(String username, String password) {
    if (userDatabase.containsKey(username)) {
        if (userDatabase.get(username).equals(password)) {
            System.out.println("Success! Welcome " + username + " to login");
            return true;
        } else {
            System.out.println("Password Error. Retry it later.");
            return false;
        }
    } else {
        System.out.println("User not found.");
        return false;
    }
    return false; // Why is this 'return false' necessary here?
}
```

The question is: Why is there a `return` statement at the end, which is the last line of the code block, even though all logical branches of the program have already returned results, covering all possible cases? Isn't this final `return` statement redundant?

This raises a famous problem in the field of computation: the Halting Problem. The Halting Problem is formulated as: Does there exist a program $P$ that, given any input program $w$, can determine whether $w$ will terminate within a finite time or enter an infinite loop?

This concept may seem abstract, but let's explain it with a real-life example: Suppose you're a student, and your math teacher is very strict, often assigning complex math homework.

One day, your teacher gives you an assignment with a strange requirement: you can only start working on it if you can prove that you can complete the math homework within a finite time, or prove that the math problem is unsolvable.

However, the problem is difficult, and you're unsure if it's beyond your capabilities, pushing you to your limits. You're stuck trying over and over again on your draft paper, not knowing when you'll find a solution. It could be a few hours, a whole night, a year, two years, or even a decade. Worse yet, you're not even sure if the problem has a solution. Many of us should be familiar with such experiences from our school days when grappling with math problems.

Alan Turing was the first to provide an unprovable proof. He concluded that the Halting Problem is unsolvable. In other words, you can never write a program $P$ that, given any input program $w$, can determine whether $w$ will terminate within a finite time or enter an infinite loop. Just like in the example above, you can never take on that math assignment; you just have to give up.

Next, we give a formal deduction for this problem:

Suppose there exists a function $H$, which takes two parameters: a program $p$ and input $i$, and can determine whether program $p$ terminates (i.e., halts) when given input $i$. $H(p, i)$ returns `true` if program $p$ halts on input $i$, otherwise `false`.

Then, we can construct a new function $D$, which takes a program $q$ as its parameter, and defines it as follows:

```plaintext
D(q) = {
    if H(q, q) returns false:
        halt
    else:
        loop forever
}
```

Now, let's consider the function $D(D)$, which takes itself as input. According to the definition of $D$:

- If $H(D, D)$ returns `false`, then according to the definition of $D$, $D(D)$ will halt.
- If $H(D, D)$ returns `true`, then according to the definition of $D$, $D(D)$ will enter an infinite loop.

Now let's observe the two possibilities for $H(D, D)$:

- If $H(D, D)$ returns `true`, then according to the definition of $D$, $D(D)$ will enter an infinite loop.
- If $H(D, D)$ returns `false`, then according to the definition of $D$, $D(D)$ will halt.

Regardless of whether $H(D, D)$ returns `true` or `false`, it leads to a contradiction with the definition of $D(D)$.

Therefore, we arrive at a paradox: If there exists a function $H$ that can determine whether any program halts, then we can use $H$ to construct a function $D$ that leads to a contradiction. Thus, the assumption is untenable, meaning such a function $H$ does not exist, thereby proving the unsolvability of the Halting Problem.

Based on the above conclusion, we can deduce that the capacity of computers is limited, meaning there's no universal algorithm that can solve all computational problems. This is a significant conclusion in computational theory.

Although Alan Turing proved the Halting Problem in the context of "Turing machines," where the problem is unsolvable, this conclusion applies to any modern computing system, even beyond computers to any algorithms or programs themselves.

Moreover, the Turing machine is an idealized computational model that assumes storage space and computing speed can be arbitrary and infinite. So, we can conclude that there's no modern computer whose performance exceeds that of a Turing machine. This indicates that computers are not omnipotent, and many problems in life cannot be solved by computers, no matter how intelligent or high-performing they are.

This can lead to another question: Can memory leaks be fundamentally avoided in program design? The answer is also negative. Upon careful consideration, it's understandable: In a program, how can we fundamentally determine the timing of memory reclamation? Or, can we prove that an object will be released within a finite time?

This problem is logically unsolvable. Languages like Rust provide numerous mechanisms at the language compilation level, but they can only address memory leaks caused by human errors to a small extent. They can only solve a small part of memory leak issues.

Now, returning to the code mentioned at the beginning of the article, why is it necessary to add a return statement at the end of the function? This is related to the compiler's strategy. Because for the compiler, whether branches in the program's business code will exit the scope is unpredictable, which relates to the halting problem discussed above. Therefore, the compiler assumes that any branch may not exit the function's scope. Consequently, the compiler must explicitly use return outside of the branches to exit the function.


How to explains the Halting Problem's unsolvability in computing, referencing Alan Turing's work. Let’s start with a simple Java login function and a example.

How to Explain The Halting Problem


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


Concerning the `useEffect` hook, [as described in the React official documentation](https://react.dev/reference/react/useEffect), it is sufficient. Unfortunately, `useEffect` is the most controversial API design in React. It is widely considered the most challenging and difficult-to-implement hook in actual projects, stemming from the contradiction between React's idealized design and the practical demands of development.

In this article, based on the prevailing community viewpoint, I will discuss my personal understanding of this issue: you should avoid using `useEffect`, as there are often better alternatives for most use cases.

## Side Effects: `useEffect`

`useEffect`, as the name implies, describes the side effects during the rendering of a component. To understand this hook, we must first comprehend what a side effect is.

> In functional programming, a "side effect" refers to any impact on the program's state other than the return value of a function. Functional programming emphasizes the concept of pure functions, where a pure function produces the same output for the same input conditions and has no side effects.

For example, consider a function simulating a bank statement query, requiring only two parameters: the account and a time range. It returns all the transaction records for the specified account within that time range. If it only returns the query result without any other operation, the function is pure:

```typescript
GetBankStatement(accountId, timeRange) {
  let data = ...... // fetch the data from the database;
  return data;
}
```

However, the bank's database is sensitive, and for security reasons, each query request must be monitored. Thus, in addition to returning the result, the function might log information about the query, such as the queried account and date:

```typescript
GetBankStatement(accountId, timeRange) {
  let data = ...... // fetch the data from the database;
  doLog("User XXXX queried account XXXX on date XXXX within the specified date range");
  return data;
}
```

Here, besides returning the query result, the function secretly logs the query operation, affecting the program's logging state. This operation represents a side effect.

In practical programming, side effects may include but are not limited to:

1. **Changing mutable data state:** Modifying external variables, object properties, or array elements to alter the program state.

2. **I/O operations:** Including reading/writing files, sending network requests, or performing operations in a database.

3. **Printing output or logging:** Outputting information to the console or logging details to a log file.

4. **Throwing exceptions:** Altering the normal program flow by raising exceptions.

5. **Modifying global variables:** Changing variable values in the global scope.

Functional programming aims to minimize or avoid side effects because they increase program complexity, reduce maintainability, and can lead to unpredictable behavior. Pure functions (functions without side effects) are easier to test, compose, and reason about.

By adhering to the principles of functional programming, code can be better controlled, readability can be improved, errors can be reduced, and programs can be more easily executed concurrently. In functional programming, it is generally encouraged to isolate side effects in specific areas of the program, such as using pure functions and the Single Responsibility Principle. If side-effect operations are needed, they can be handled at the edge of the program rather than in the core business logic.

Let's start with functional programming.

React, as a library for describing UIs, initially embraced some functional programming concepts. It uses JSX to encapsulate page elements into components with attributes. Given the input attributes, a component processes them logically and renders them as UI. This is similar to the mapping relationship between attributes and UI outputs in a function. In mathematical language, a function is a description of a mapping relationship: for a given, definite input, there is always a specific, unique output. This is also the requirement for functions in functional programming.

This is the ideal React component.

However, the problem is that although React borrows functional ideas, most components are not ideal components because each component may have its own state (`State`). States change with the internal logic of the component. According to the above definition, these changes are also considered side effects. Therefore, React does **not strictly** follow the idea of functions to describe the mapping relationship between input attributes and UI outputs.

## Two Main Use Cases

The React official documentation shows 10 examples to illustrate the use cases of `useEffect`. In my view, their use cases can be **essentially** divided into two main categories: initializing components and refreshing components.

### Initializing Components

Let's consider an example of developing an online bookstore app. We have a product book list displaying basic information such as book title, author, and price.

```typescript
function BooksList() {
  const [listData, setListData] = useState([]);
  return (
    <ol>
      {listData.map((item, index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>
      ))}
    </ol>
  );
}
```

When the app starts, this component is mounted, and its initial data state `listData` is an empty list, so it doesn't render anything.

Now, if I want the app to push the latest book list to the user upon launch, I need to fetch data from the server, initialize the component, and provide the fetched data as the initial data value for `listData`.

Here, `useEffect` provides a way to execute side effects **only after the component is first mounted**: by setting the dependency array to an empty array. Let's modify the code:

```typescript
function BooksList() {
  const [listData, setListData] = useState([]);

  useEffect(() => {
    fetch('https://my-api.com/get-latest-books')
      .then((res) => {
        setListData([...res.json()]);
      });
  }, []);
  // Here, the effect runs only once after the component is first mounted,
  // fetching data from the server, setting it to the state, and rendering it.
  // This way, the component gets an initial value, completing its initialization.

  return (
    <ol>
      {listData.map((item, index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>
      ))}
    </ol>
  );
}
```

Now, when `BooksList` is mounted, it executes the `fetch` operation to get initial data, updates `listData`, and renders the initial data, completing the component initialization.

Now, let's say I want to provide feedback to the user while the data is loading. I want to display a "Loading..." message and a loading animation during the fetch operation, and then display the list once the data is loaded. How do I achieve this?

We'll add another state, `isLoading`, to indicate whether the list is currently loading. If it is loading, show the loading animation and text. After loading, display the list and unset the loading state.

So, the code is modified as follows:

```typescript
function BooksList() {
  const [listData, setListData] = useState([]);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetch('https://my-api.com/get-latest-books')
      .then((res) => {
        setListData([...res.json()]);
        setIsLoading(false);
      });
  }, []);

  return (
    <>
      {isLoading ?
        <div>
          <LoadingAnimation />
          <p>{"Loading..."}</p>
        </div>
        :
        <ol>
          {listData.map((item, index) => (
            <li>
              <h2>{item.title}</h2>
              <p>{item.author}</p>
              <p>{item.price}</p>
            </li>
          ))}
        </ol>
      }
    </>
  );
}
```

In this example, `fetch` and `setIsLoading` are part of the effect executed when the component is mounted and rendered. Here, the effect provides an indication of the loading logic during the initial rendering of the component.

### Accompanying Component State Refresh

A commonly encountered scenario is pagination.

For instance, I have a book list page, simplified as follows:

```typescript
export default function BooksListPage() {

  const [listData, setListData] = useState([]);
  const [currentPage, setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum: number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res) => {
        setListData([...res.json()])
      })
  }

  useEffect(() => {
    handleLoadListData(currentPage);
  }, [])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`Current Page: ${pageNum}`}</p>
      <button
        onClick={() => setCurrentPage(currentPage - 1)}
      >
        {"Previous Page"}
      </button>
      <button
        onClick={() => setCurrentPage(currentPage + 1)}
      >
        {"Next Page"}
      </button>
    </main>
  )
}
```

The above code represents pagination for the `BooksList` component. It includes a `currentPage` to indicate the current page number. Based on this page number, the API is called to load the corresponding list. Now that the initialization of the component is done, how do we implement loading the list corresponding to the new page number when the "Previous Page" or "Next Page" button is clicked?

Firstly, note that we are changing the `currentPage` state, and loading the corresponding list is an operation influenced by the changed state, modifying the `listData` state at the same time. In essence, loading the corresponding list is an effect.

Therefore, we can set up a `useEffect` with a loading new page list effect. The condition for this effect to take place is a change in `currentPage`.

```typescript
export default function BooksListPage() {

  const [listData, setListData] = useState([]);
  const [currentPage, setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum: number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res) => {
        setListData([...res.json()])
      })
  }

  useEffect(() => {
    handleLoadListData(currentPage);
  }, [])

  useEffect(() => {
    handleLoadListData(currentPage)
  }, [currentPage])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`Current Page: ${pageNum}`}</p>
      <button
        onClick={() => setCurrentPage(currentPage - 1)}
      >
        {"Previous Page"}
      </button>
      <button
        onClick={() => setCurrentPage(currentPage + 1)}
      >
        {"Next Page"}
      </button>
    </main>
  )
}
```

Now, when the `currentPage` state changes, it automatically executes the effect to load the corresponding list. This achieves the refreshing of the component's state.

### Drawbacks

Both of the above use cases have a strict prerequisite: **effect operations must be idempotent**. Idempotence means that for an operation, the initial operation and subsequent operations must be entirely equivalent.

For example, in database operations, read (`GET`), search, delete, and update (`PUT`, `POST`, `DELETE`) are idempotent operations. When we query data from the database, the database's state does not change. The first query for specific data and subsequent queries for the same data yield equivalent results. Therefore, querying data is an idempotent operation.

However, when we perform create (`POST`), delete (`DELETE`), or update (`PUT`) operations on data, the state of the affected data changes: new data is added, existing data is deleted, or existing data is modified. These operations are non-idempotent.

This is where the dilemma of `useEffect` lies.

React, initially designed as a library for declarative UI construction, primarily focuses on the relationship between input data flow, state data flow, and output UI. It relies on the unidirectional data flow of input → state → output to produce the final result.

Since the input data flow is dynamic and can change at any time, and states can change at any time based on internal business logic, and states' uncertainty determines the uncertainty of UI rendering results:

> **Note:** For performance reasons, even after updating the state to the latest data using `setState`, React may not immediately render the UI based on the latest state. It waits to collect enough latest states before batch updating and rendering. For more details, refer to the official documentation.

So, React cannot accurately determine when a component will be re-rendered based on state changes and cannot predict how many times it will be re-rendered. In other words, you cannot precisely anticipate the next step after an operation, whether the component will be refreshed or re-rendered.

Therefore, if you treat a non-idempotent operation as an effect, it can lead to inconsistencies between data and UI

.

On Twitter and GitHub, developers often complain that in debug mode, `useEffect` is executed twice, leading to bugs. In reality, they completely misunderstand the actual purpose of `useEffect` and incorrectly use it as an event listener for state changes.

Simply remembering this rule can help avoid misusing `useEffect`:

> The effect of `useEffect` should only be used for idempotent view initialization and view refresh. Beyond this, it has no other purpose and should not be used for any business logic.

Although this statement might sound absolute and somewhat harsh, it can fundamentally prevent misuse of `useEffect`.

For example, if you use a non-idempotent operation as an effect:

```typescript
function BooksManager() {
  const [listData, setListData] = useState([]);

  const handleAddNewBook = (book) => {
    setListData((prevListData) => [book, ...prevListData]);
  };

  useEffect(() => {
    axios.post("https://my-api.com/add-book", {
      body: listData[0],
    });
  });

  // ....
}
```

What's wrong with the above code?

It attempts to immediately sync the added book to the server after adding a new item to the data list. However, "Adding a new book" itself is not an idempotent operation. This effect not only triggers after the `listData` state changes but also after the parent component re-renders, with an unpredictable number of triggers.

Now, let's add a dependency array to this `useEffect`, restricting it to trigger only after `listData` changes. How about this?

```typescript
useEffect(() => {
  axios.post("https://my-api.com/add-book", {
    body: listData[0],
  });
}, [listData]);
```

This approach is very risky.

Because once I execute

```typescript
setListData([...listData]);
```

The data table itself has not changed, and there is no new book added. Even though the comparison of various rendering nodes in the Diff process has not changed, the reference to the array in the state data has changed. It might still trigger the effect, causing the repetitive addition of existing books.

### Point of No Return

After all that discussion, let me share my personal perspective on `useEffect`. Unfortunately, `useEffect` is a fundamentally flawed and irreparable mistake. Numerous bugs and accidents have resulted from `useEffect`, and it has become the cause of various issues.

There is a well-known incident on Twitter's web platform where developers forgot to add a dependency array to `useEffect`, leading to a massive number of GET requests, eventually crashing Twitter's servers. Initially, the cause of this bug was not identified, and the event of Twitter's service overload was mistakenly attributed to a network crawler attack launched by competitors. As a response, Elon Musk set a daily browsing limit for Twitter, resulting in an unintentional incident.

Due to its roots in React's core design philosophy, this kind of error is irreversible.

I once came across an answer on Zhihu (Chinese Q&A platform) that pinpointed the problem well:

> The essence of GUI is a state machine with a lifecycle. It is the result of the interaction between state data and the view, not a simple F(x).

The writing style of `useEffect` in React is indeed awkward, and it made many fundamental mistakes from the beginning. Various optimization techniques and hooks introduced later are just patching up these issues.

For instance, the uncertainty of states leads to the uncertainty of rendering, sometimes causing redundant rendering, and developers have to use methods like `useMemo`, `useCallback`, `React.memo` to avoid redundant rendering. All optimizations must be done manually, adding to the cognitive burden and making React's performance rank lower compared to other frameworks.

Frameworks like Vue do not have these issues. Vue's performance is even better than React.

However, React, despite its many pitfalls in this regard, is still considered an excellent front-end framework after years of development. When learning React, it is crucial to learn from these "pitfalls" and avoid such practices, rather than getting bogged down in the details of peculiarities in writing.

As one wise developer summarized:

> Many people mentioned the most critical point below: the state in asynchronous side effects should not be out of sync, `useEffect` is not a lifecycle, not `didUpdate`. Dependencies are just a helpless move limited by the nature of the JavaScript language, and it's not a feature. Therefore, no business logic should depend on dependencies to be implemented.


The article discusses the challenges and pitfalls of using useEffect in React, emphasizing its proper application for idempotent view initialization and refresh, cautioning against non-idempotent operations to avoid inconsistencies between data and UI.

The Usages and Traps of useEffect in React


对于 useEffect 这个 hook，[我认为 React 官方文档中所述备矣](https://react.dev/reference/react/useEffect)。但不幸的是，对于 useEffect，它是 React 中受到争议最大的 API 设计。人们普遍认为他是 React 中最难以理解、最难以在项目中实际投入使用的 hook，源于 React 过于理想化设计与实际开发需求脱节之矛盾。

本文在采取社区的主流观点后就此问题来谈谈我的个人理解：你应当避免使用 useEffect，它在大多数用途中可以以另一种更好的方案替代之。

## 副作用：Effect

useEffect，顾名思义：它描述的是组件渲染时的副作用。要理解这个 hooks，我们必须先理解什么是副作用。

> 在函数式编程中，"副作用" 是指函数除了返回值之外对程序状态产生的任何影响。函数式编程强调纯函数的概念，而纯函数是指在相同的输入条件下总是产生相同的输出，并且没有副作用。

举个例子，假设有一个函数，模拟银行查询流水记录，只需要输入账号、时间范围两个参数，就返回这段时间范围内指定账户的所有流水记录。如果只返回查询结果，什么也不操作。函数大约如下：

```typescript
GetBankStatement(accountId,timeRange){
  let data = ...... // fetch the data from database;
  return data;
}
```

这种函数叫纯函数。

但是，银行的数据库是很敏感的数据信息，为了防止滥用查询职权，要求必须监视每一个查询请求，每查询一笔流水记录，就必须在日志中记录何时查询的、被查询账户等信息。

```typescript
GetBankStatement(accountId,timeRange){
  let data = ...... // fetch the data from database;
  doLog("xxxx 在 xxxx 年 xxxx 日 查询了 xxxx 的账户，被查询的日期范围为 xxxx");
  return data;
}
```

它除了返回查询结果，还暗自做了查询日志记录，记录每一笔查询操作。这种操作就是除了返回结果值以外，也对程序日志记录的状态造成了影响，这种操作就是副作用。

在实际编程中，副作用可能包括但不限于：

1. **改变可变数据状态：** 函数修改外部变量、对象属性或数组元素，从而改变程序状态。

2. **I/O 操作：** 包括读写文件、发送网络请求、在数据库中进行操作等。

3. **打印输出或日志记录：** 将信息输出到控制台或记录到日志文件。

4. **抛出异常：** 改变正常的程序流程，引发异常。

5. **修改全局变量：** 改变全局作用域中的变量值。

函数式编程试图最小化或避免副作用，因为它们会增加程序的复杂性、降低可维护性，并且可能引发不可预测的行为。纯函数（无副作用的函数）更易于测试、组合和推理。

通过遵循函数式编程的原则，可以更好地控制代码，提高可读性，减少错误，并使程序更容易并发执行。在函数式编程中，通常鼓励将副作用隔离在程序的特定区域，例如通过使用纯函数和单一职责原则。如果需要进行有副作用的操作，可以在程序的边缘处理，而不是在核心业务逻辑中。

首先我们就从函数式编程来入手

React 作为描述 UI 的基础库，早期拥抱了函数式编程的部分思想：它使用 JSX 将页面元组封装成一个具有属性的组件，给定该组件的属性输入，则组件将输入属性进行逻辑处理后渲染成 UI。实际上这类似于函数中属性到输出 UI 直接的映射关系。大概为

$$
F(props) => UI
$$

在数学语言中，函数（Function）是对映射关系的描述：对于给定的确定输入，总是有确定的、唯一的输出。这也是函数式编程中对函数的要求。

这就是理想的 React 组件。

但问题是：React 虽然借鉴了函数式思想，但大多数组件并不是理想组件，因为每个组件可能会有自己的状态 (State)，而状态是会跟着组件内部逻辑发生改变的，按照上面的定义，这种改变也叫副作用，所以 React **并不是** 按照严格的函数思想来描述输入属性与输出 UI 的关系的。也就是说，输入属性并不一定严格映射到唯一的 UI 输出。

## 两大用途

useEffect 在官方文档中展示了 10 类样例来展示用途。在我看来，其实它们的用途 **本质** 上可以分为两大类：初始化组件和刷新组件。

### 初始化组件

考虑我们开设一个在线书店的 APP，我们有一个商品书目列表，它标注了书名、作者、价格的基础信息。

```typescript
function BooksList() {
  const [listData,setListData] = useState([]);
  return (
    <ol>
      {listData.map((item,index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>)
      )}
    </ol>
  )
}
```

当 App 启动后，这个组件被挂载时，它的初始数据状态 `listData` 为空列表，它当然什么也不会渲染。

那么，如果我希望 App 一启动后，就给用户推送最新上市的书目列表，那么我们就要在组件挂载后，从服务端拉取数据，给组件初始化一下，赋予拉取的数据作为一个初始的数据值放到`listData`中。

所以，`useEffect` 提供了一种 **只在组件首次挂载后执行** 的副作用方法：把依赖数组置为空数组即可。把上面的代码再修改一下，大概写成如此：

```typescript
function BooksList() {
  const [listData,setListData] = useState([]);

  useEffect(()=>{
    fetch('https://my-api.com/get-latest-books')
      .then((res)=>{
        setListData([...res.json()])
      });
  },[])
  // 在这里，effect 只会在组件首次挂载时拉取服务器数据，
  // 设置到 state 中并渲染出来。
  // 这样组件就获得了一个初始值，也就完成了组件的初始化。

  return (
    <ol>
      {listData.map((item,index) => (
        <li>
          <h2>{item.title}</h2>
          <p>{item.author}</p>
          <p>{item.price}</p>
        </li>)
      )}
    </ol>
  )
}
```

这样，当 `BooksList` 被挂载后，会执行 `fetch` 操作获取初始数据，更新到 `listData` 中，并且把初始数据渲染出来，就完成了组件的初始化。

那么问题来了，如果我希望在加载数据时给予用户以反馈，在加载时显示「数据正在加载中」这个提示，又该怎么做呢？

我们再加上一个 state，为 `isLoading` ，来指示列表是否正在加载中。如果加载中，那么显示加载动画和文字提示，且加载完以后显示列表，并取消加载状态。

那么我们的代码改写如下

```typescript
function BooksList() {
  const [listData,setListData] = useState([]);
  const [isLoading,setIsLoading] = useState(false);

  useEffect(()=>{
    setIsLoading(true)
    fetch('https://my-api.com/get-latest-books')
      .then((res)=>{
        setListData([...res.json()])
        setIsLoading(false)
      });
  },[])

  return (
    <>
    { isLoading ?
      <div>
        <LoadingAnimation/>
        <p>{"正在加载中"}</p>
      </div>
      :
      <ol>
        {listData.map((item,index) => (
          <li>
            <h2>{item.title}</h2>
            <p>{item.author}</p>
            <p>{item.price}</p>
          </li>)
        )}
      </ol>
    }
    </>
  )
}
```

在这里 fetch 和 setIsLoading 都是在组件挂载、渲染时的 effect。在这里，effect 提供了首次挂在组件时的状态、视图行为的指示，属于「加载的逻辑」。

### 伴随刷新组件状态

一个常用的场景就是分页查询。

比如，我有一个书籍列表页，简化如下：

```typescript

export default function BooksListPage() {

  const [listData,setListData] = useState([]);
  const [currentPage,setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum:number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res)=>{
        setListData([...res.json()])
      })
  }

  useEffect(()=>{
    handleLoadListData(currentPage);
  },[])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`现在是第 ${pageNum} 页`}</p>
      <button>
        {"上一页"}
      </button>
      <button>
        {"下一页"}
      </button>
    </main>
  )
}

```

以上写法是对 BooksList 列表的分页查询。我们放了一个 currentPage 来指示当前的页码。并且根据当前的页码 currentPage 来调用 API，加载对应的列表。现在，初始化组件的代码已经写好了，那么我们应该如何实现点击上一页、下一页按钮后，当前页码状态变化后，加载新页码对应的列表呢？

首先注意到：我们改变的是 currentPage 这个 State，而加载对应的列表则是受到 state 变化影响后的操作，加载对应的列表也同时修改了 listData 的 state。

实际上，加载对应列表就是一个 effect。

所以，我们可以设置一个 useEffect，加一个加载新页列表的 effect，这个 effect 的生效前提就是 currentPage 发生变化。

```typescript

export default function BooksListPage() {

  const [listData,setListData] = useState([]);
  const [currentPage,setCurrentPage] = useState(1);

  const handleLoadListData = (pageNum:number) => {
    fetch(`https://my-api.com/books-list/${pageNum}`)
      .then((res)=>{
        setListData([...res.json()])
      })
  }

  useEffect(()=>{
    handleLoadListData(currentPage);
  },[])

  useEffect(()=>{
    handleLoadListData(currentPage)
  },[currentPage])

  return (
    <main>
      <BooksList data={listData} />
      <p>{`现在是第 ${pageNum} 页`}</p>
      <button
        onClick={()=>setCurrentPage(currentPage - 1)}
      >
        {"上一页"}
      </button>
      <button
        onClick={()=>setCurrentPage(currentPage + 1)}
      >
        {"下一页"}
      </button>
    </main>
  )
}

```

这样当 currentPage 的 state 发生变化后，它会自动执行加载对应列表的 effect，这样就实现了组件的状态刷新。

### 缺陷

以上两类用途都有一个严格的前提：**effect 操作必须是幂等性操作**。幂等性，也就是说对于一个操作，初始操作和后续操作必须完全等效。

举个例子，在数据库操作中的增、查、删、改。我们查找数据库中的数据时，库中的数据并没有发生任何变化，我们第一次查询某个数据和后续多次查询这条数据，都不会对这个数据本身造成任何改动，既第一次操作和后续操作是完全等效的。所以查询数据就是一个幂等性操作。

但是我们要增、删、改数据时，被操作的数据就发生了变化：原先库中不存在的数据存在了，或者原先存在的数据不存在了，或者原先存在的数据被改动了一部分，都对数据库的总体数据添加了变化；这种操作就是非幂等性操作。

这也是 useEffect 的尴尬所在。

React 最初只是作为一种声明式构建、描述 UI 的库，它只重点关注输入数据流、状态数据流和输出 UI 三者之间的关系。它依赖输入→状态→输出这条单向链式数据流路线得到最终结果。

因为输入数据流是不确定的、随时的，也就导致状态也是不确定，再加上状态可以在组件内被业务逻辑随时更改，而状态的不确定性也就决定了 UI 渲染结果的不确定性。

> **注意：** 出于性能优化的原因，即使是 setState 操作更新 state 到最新数据后，React 也不一定会立即根据最新的 state 来渲染 UI，而是等待收集到足够多的最新 state 后批量更新、渲染。具体内容请了解官方文档。

所以 React 并不能准确确定组件什么时候会根据状态重新被刷新、渲染，也不能确定它会被刷新、渲染多少次。也就是说，你不能准确预料到某个操作后的下一步，组件是否会被刷新、重渲染。

所以，如果你把非幂等性操作作为 effect，那么就会导致数据与 UI 的不一致。

在 twitter, github 上，我常看到很多开发者抱怨 React 会在 debug 模式下，useEffect 中会执行两次 effect 操作而产生 BUG。实际上，他们是完全误解了 effect 的实际意义，误把 effect 当成 state 的事件监听器来使用。

只需要记住这条法则就能避免误用 effect :

> useEffect 的 Effect 只能用于幂等性的视图初始化、视图刷新，除此之外别无用途，更不应当用于任何业务逻辑。

虽然话说得很绝对，有一棒子打死的嫌疑，但是可以从根本上杜绝对 useEffect 误解而造成的滥用。

举一个例子，假如我们在在线商城的后台维护一个商品书目列表，对于「添加新书」的操作就不应当作为 effect。

```typescript
function BooksManager() {
  const [listData, setListData] = useState([]);

  const handleAddNewBook = (book) => {
    setListData((prevListData) => [book, ...prevListData]);
  };

  useEffect(() => {
    axios.post("https://my-api.com/add-book", {
      body: listData[0],
    });
  });

  // ....
}
```

以上代码有什么问题？

它试图在数据列表添加新项后马上同步提交到服务器，但是「添加新书」本身就不是一个幂等操作，这个 effect 不止会在 listData 的 state 改变后触发，也会在父组件重渲染后触发，触发次数也不确定。

那么，为这个 useEffect 加上依赖数组，限定只能在 listData 变化后触发，如何？

```typescript
useEffect(() => {
  axios.post("https://my-api.com/add-book", {
    body: listData[0],
  });
}, [listData]);
```

这么做是非常有风险的。

因为我一旦执行

```typescript
setListData([...listData]);
```

表数据本身没变，没有添加新书，根据 Diff 比较各个渲染节点也没变，但是状态数据中的数组引用变了，还是可能会触发 effect，会重复添加已有的书籍。

### 积重难返

上面说了那么多，接下来讲讲我的个人对 useEffect 的观点。很遗憾，useEffect 是非常失败的、无法挽回的错误。因 useEffect 造成的 bug、事故数不胜数。

传言 twitter 的网页端就曾发生过，twitter 程序员忘了给 useEffect 加上依赖数组，导致 useEffect 大量发送 GET 请求，以至于 twitter 的服务器直接崩溃。而且这种 Bug 事故原因一开始也没查出来，twitter 服务负载崩溃事件传到高层后，Elon Musk 以为是对手发动的网络爬虫攻击，于是给 twitter 设置了一天浏览量上限的乌龙事件。

因为它根植于 React 的底层核心设计思想，所以这种错误无法挽回。

我曾在知乎上看到过一个回答，很好地点出了问题所在：

> GUI 的本质是一个有生命周期的状态机，是状态数据、视图相互作用的结果，而不是单纯的 F(x)。

React 的 useEffect 写法确实很别扭，它从一开始就犯了很多根本性错误，由此衍生出的很多 hooks 优化手段不过是拆东补西。

比如状态的不确定性导致渲染的不确定性，有时会造成重复渲染浪费性能，就不得不用 `useMemo`、`useCallback`、`React.memo` 之类的方法来避免重复渲染，一切优化必须靠手动，徒增心智负担，导致 React 的性能在诸位框架中属于垫底的存在。

像 Vue 的框架就完全没有这个问题。Vue 的性能更是比 React 高出不少。

不过它是首批声明式前端 UI 框架，在这方面虽然走出了一些弯路，但经过多年实践，探索结果也未必没有意义。React 官方文档里也详细记录了很多坑，以及大大小小的修补方案。

虽然 React 这方面的坑比较多，但经过多年发展 React 仍然不失为一种优秀的前端框架。**在学习 React 时，对于这些「坑」应当吸取教训、避开这种写法，而不是在茴香豆的写法上钻牛角尖。**

正如同一位知友的总结：

> 下面很多人都提到了最关键的一点，不同步副作用中的状态不是 hooks 的标准做法，useEffect 更不是生命周期，不是 didUpdate. deps 只是受制于 JS 语言特性的无奈之举，并不是一种特性，所以任何业务不应该依赖于 deps 去实现。


文章讨论了在 React 中使用 useEffect 的挑战和陷阱，强调其在幂等视图初始化和刷新方面的正确应用，并警告不要进行非幂等操作，以避免数据和 UI 之间的不一致。

React 中的 useEffect 用途和一些坑


GraphQL is a query language for APIs proposed by Facebook. Many consider it as an alternative to REST, while others find GraphQL more complex than REST with no clear benefits. What unique capabilities does GraphQL have beyond the scope of REST? Is there an objective and rigorous criterion to help us make a judgment?

Nop Platform, through rigorous mathematical reasoning, has reinterpreted the positioning of GraphQL, resulting in new design ideas and technical implementation solutions. Under this interpretation, the NopGraphQL engine achieves comprehensive superiority over REST, strictly speaking, in the mathematical sense.

In simple terms, **GraphQL can be seen as an improvement of REST in a pull mode**, to some extent, it **reverses the flow of information**.

```text
query {
    NopAuthDept__findAll {
        name, status, children {name, status}
    }
}
```

Equivalent to `/r/NopAuthDept__findAll?@selection=name,status,children{name,status}`

Through **mathematical equivalence transformations (form transformations)**, we can clearly see that GraphQL is essentially supplementing a standardized `@selection` parameter to REST, allowing selective fetching of results.

Traditional REST is equivalent to pushing all information from the backend to the frontend, where the frontend cannot finely participate in the information production and transmission process. In the implementation of NopGraphQL, if the frontend does not request the `@selection` parameter, it automatically degrades to the traditional REST model, returning all non-lazy fields. Lazy fields need to be explicitly specified for them to be returned to the frontend.

In the architecture of Nop Platform, GraphQL is not just a transport protocol on par with REST; it is a **universal mechanism for information decomposition and composition**. It helps us organize the information structure of the system more effectively.

The positioning of NopGraphQL is as a general decomposition and dispatch mechanism for backend service functions. The same service function can be simultaneously published as a REST service, GraphQL service, gRPC service, Kafka message service, Batch processing service, etc. In simple terms, any scenario that involves receiving a Request Message and returning a Response Message can be directly integrated with the NopGraphQL engine as its implementation mechanism.

Using GraphQL has the following advantages compared to traditional REST:

## 1. Automatically trimming data loading scope based on requested data, achieving performance optimization

```text
@BizQuery
public PageBean<NopAuthUser> findPage(@Name("query") QueryBean query, FieldSelectionBean selection, IServiceContext context){
    PageBean<NopAuthUser> pageBean = new PageBean();
    if(selection != null && !selection.hasField("total")){
        long total = dao.countByQuery(query);
        pageBean.setTotal(total);
    }
    // ...
}
```

If the frontend does not require the total to be returned, the calculation of the total property can be skipped.

## 2. Automatic DTO adaptation by the engine, greatly enhancing the composability of data models

In traditional REST services, service functions directly return DTO objects, and all properties of DTO objects must be loaded in the service function. For example, if a virtual roles field is added to the NopAuthUser entity, it needs to be added to the DTO, and all places that return NopAuthUserDTO need to supplement the loading logic for the roles field. In NopGraphQL engine, the object returned by the service function is not directly serialized into JSON and returned to the frontend. Instead, it is processed further by the GraphQL engine using DataLoader to obtain the final returned data. This can significantly improve the composability of backend data models.

```java
@BizQuery
public List<NopAuthUser> findList(){
    // ...
}

@BizQuery
public NopAuthUser get(@Name("id") String id){
    // ...
}

@BizLoader
public List<String> roles(@ContextSource NopAuthUser user){
    // ...
}
```

In the example above, the findList and get functions only need to know how to load NopAuthUser objects, without needing to know how NopAuthUser is associated with NopAuthRole objects. Service functions can directly return entity objects without the need for manual translation into DTO objects. When we add a dynamic property roles to the NopAuthUser type through the `@BizLoader` mechanism, all places in the returned result that involve NopAuthUser automatically gain the roles property. The knowledge provided by DataLoader, through the action of the NopGraphQL engine, automatically combines with the functions we manually write, such as get/findList.

In NopGraphQL, we can also use an additional xmeta metamodel file to independently control the permissions, transformation, and validation logic of each field, simplifying and standardizing the implementation of service functions.

## 3. GraphQL's selection capability is a beneficial complement to the concept of aggregate roots in DDD

In Domain Driven Design (DDD), a critical and important design for information space planning is the concept of aggregate roots. Aggregate roots act as core nodes in the information space, allowing traversal in the information space by establishing direct connections with a few core nodes. Aggregates organize information in a form on the surface, reducing cognitive and usage costs, but it also has a negative impact on performance. GraphQL's selection capability is a complementary ability to the ability to aggregate (aggregation and selection as dual operations should be paired in design). It allows us to selectively extract slices of information we need from a vastly complex information structure, precisely meeting our business requirements.

## 4. GraphQL clearly distinguishes between query and mutation in terms of semantics, aligning more with the original intent of REST's Representational State Transfer design

Although REST specifies GET and POST methods, due to limitations at the implementation level (GET method does not support passing data through the HTTP body, URL length limitations, and security issues), we often cannot accurately differentiate the semantics of service functions through GET/POST. In the NopGraphQL framework, it is conventionally agreed that queries have no side effects and do not modify the database, while mutations have side effects and require consideration of transaction management, etc. Therefore, in the NopGraphQL framework, there is no need to manually add the `@Transactional` annotation for each service function; instead, a unified transaction environment is established for all mutation operations. Through optimizations at the implementation level, if a mutation does not actually access the database, the NopGraphQL framework does not actually obtain a database connection.

The NopGraphQL engine decomposes the execution of backend service functions into two phases: 1. Execute the service function, automatically establishing a transaction environment for mutations. 2. Process the result object returned by the service function, performing data transformation and pruning through DataLoader.

After the first phase is completed, the transaction is automatically closed, and some resource-consuming data loading tasks do not start executing. In the second phase, the transaction is closed, and the OrmSession is set to readonly. If entity data is inadvertently modified, an exception is automatically thrown. In this way, we can reduce the time the transaction is open and the time the database connection is occupied.


This article analyzes GraphQL's unique capabilities in API design, highlighting its advantages over REST, such as optimized data loading, enhanced data model composability, and improved semantic clarity in queries and mutations.

Why the Graphql Is Better than Restful in Math Conclusion?


_The Road to Serfdom_ is a work by Friedrich Hayek, published in 1944 with the full title "The Road to Serfdom: The Path to Individualism and Social Order." The book primarily explores the negative impact of collectivism and planned economies on individual freedom and social order.

**Key Points and Arguments:**

1. **Planned Economy Leads to Serfdom:** Hayek argues that excessive central planning and collectivist ideologies can result in political serfdom. He cautions that when governments attempt to excessively intervene in the economy and society, it may ultimately harm individual freedom, leading to a state of despotism.

2. **Free Market and Individualism:** The book advocates for free markets and individualism as effective means to ensure individual freedom and societal prosperity. Hayek believes that market mechanisms better satisfy people's needs, while excessive intervention distorts the market, leading to adverse consequences.

3. **Importance of Social Order:** The author contends that social order is not achieved through central planning but rather through the individual's free choices and market competition. Excessive concentration of governmental power may disrupt this order, causing chaos and instability.

In addition to the main points mentioned above, Friedrich Hayek presents several other significant ideas in _The Road to Serfdom_:

1. **Knowledge Problem of Planned Economies:** Hayek highlights the difficulty of central planning in effectively acquiring and utilizing dispersed knowledge within society. He argues that market mechanisms, through price systems, can transmit vast amounts of decentralized information, which central planning often fails to achieve.

2. **Individual Freedom and Social Responsibility:** The book emphasizes that individual freedom is not unlimited but exists within the framework of the rule of law. Hayek suggests that in a free society, individuals should bear some social responsibility for their actions to maintain overall social order.

3. **Defense of Liberalism:** _The Road to Serfdom_ serves as Hayek's defense of liberalism. He asserts that liberalism is not indifferent to societal issues but addresses them through the free choices of individuals and market competition while maintaining the rule of law and social order.

4. **Evolution of Social Rules:** The author stresses that the evolution of social rules should be a continuous process of adaptation to change, not dictated by central planning. He believes that the evolution of social rules occurs through the practical experiences of individuals, rather than through abstract theoretical planning.

These ideas collectively form the complex and profound liberal theory in "The Road to Serfdom," aiming to elucidate the relationship between free markets, individual freedom, and social order, as well as the potential negative consequences of central planning on these relationships.

**Methods of Argumentation:**

1. **Historical Case Analysis:** By analyzing the history of Nazi Germany and the Soviet Union, Hayek illustrates the relationship between planned economies and totalitarianism, aiming to demonstrate that planned economies may lead to the loss of individual freedom.

2. **Economic Theory and Market Principles:** The book employs economic and market principles to explain how market mechanisms, through supply and demand relationships and individual choices, efficiently allocate resources, positively impacting social order.

**Conclusion:**
The conclusion of _The Road to Serfdom_ is that to preserve individual freedom and social order, one should avoid excessive central planning and collectivist ideologies. Individualism and free-market mechanisms are considered key factors in constructing a robust social order.

In summary, Hayek presents a critique of planned economies and collectivism in this book, emphasizing the importance of individual freedom and market mechanisms for society. This has established _The Road to Serfdom_ as a classic in 20th-century liberal thought.


The Road to Serfdom by Friedrich Hayek warns against planned economies, advocating for free markets and individualism to safeguard freedom and societal order. Hayek critiques central planning, emphasizing the knowledge problem and the evolution of social rules, defending liberalism as a solution.

原点日志

ALL POSTS