Note: Currently, this blog has problems supporting JSX syntax, so it may not be easy to read the code. I will fix it as soon as possible.

This title pays tribute to a series of books that people who write JavaScript have heard of even if they haven’t read them: You Don’t Know JS by Kyle Simpson. It talks about many things about JS that many people don’t know.

And I don’t know React is a series of records I made for myself, recording some React that I don’t know, and these articles are summarized from my experience using React. Some of the errors I have encountered may be very basic and common (just like those written in the official documents, but I didn’t read them carefully, so I don’t know), and some may be relatively rare (I may encounter them only after writing for three or four years at work).

In other words, the spirit of writing this series is different from YDKJS. The former wants to tell you some things about JS that few people know, and it feels like “I will teach you how to write JS”. The reason why I wrote this series called “I don’t know” is because I want to use a series of articles to record the misunderstandings or omissions I have encountered when writing React, and what is the correct answer.

I don’t know how many articles this series will have. I will post an article every time I make a mistake. There is a big difference in this series that I think is quite large. I will try to provide the scene where the mistake was made at the beginning of the article, so that everyone has the opportunity to debug before seeing the answer and see if they can find out where the error is. I think this is actually the most essential part. This is not a standardized interview question, nor is it a React quiz randomly found on the Internet, but a real situation I have encountered at work.

Because I want everyone to immerse themselves in the situation as much as possible and think about the problems I have encountered, there will be a lot of space for “defining and reproducing problems”. If you are not interested in finding answers yourself, you can also skip this part and go directly to see the answer. But I personally recommend that you try to debug it yourself first, find out where the problem is, and then come to see the answer in the article, so that you can fully absorb what the article wants to express.

Anyway, let’s take a look at the case we want to talk about in this article!

Read More


Recently, I came across an article on the front-end community on Facebook: Understanding React useEffect 02, which discusses the usage of useEffect. There was also some discussion in the comments section.

Initially, I found the usage in the article a bit strange, but I could somewhat understand why it was written that way. However, I still found it odd. I wanted to leave a comment, but then I thought, “Maybe I’m the one who’s mistaken,” so I decided to think about it some more. After careful consideration, I realized that I was the one who was mistaken.

Therefore, in this post, I will share my thoughts. If there are any mistakes, please feel free to leave a comment below or discuss it with me in the front-end community. Before continuing to read, I recommend reading the original article and the discussion below it to better understand the context.

Read More


To learn something new, it’s not very useful to just read about it. The best way is to get your hands dirty and start doing it. Since React hooks had just come out when I was about to leave my previous job, I had never written hooks before, only seen some basic tutorials. But after starting my new job, I finally started writing function components + hooks.

Although I initially missed the class syntax, I found hooks to be quite good after writing them for a while. In the process of using hooks, I also encountered some common problems that people who are new to them often face. After careful study, I found that the case I want to discuss in this article is quite good. If you can understand this case, you should be able to grasp the fundamental differences between class and function components. Therefore, I wrote this article to record my experience.

By the way, if you have been writing function components for a while, are quite used to hooks, and have read the official documentation and Dan Abramov’s articles carefully, you probably won’t gain any new knowledge from this article. This article is suitable for those who have just switched to function components and are not sure what the differences are between them and class components.

Read More


Recently, a student asked me a question about the difference between keyPress and keyDown events in React, as well as the difference between keyCode and charCode. Sometimes, they could get the values, but sometimes they couldn’t, and they were confused.

At first, I thought React had done some processing, so I looked at the source code. Later, I found that React did indeed do some processing, but in fact, this problem had nothing to do with React. The difference between keyPress and keyDown is a native JavaScript event mechanism.

Although this problem has nothing to do with React, it is still a good thing to be able to refer to React’s implementation through an actual problem, and React’s comments are well written.

Therefore, this article will first show you the differences between these two events, and finally, we will see how React handles them.

Read More


Although I’ve heard about React replacing its internal reconciler with something called Fiber for a long time, I’ve never studied it in detail and didn’t know what impact this change would have on higher-level components.

I only began to understand it more deeply when I encountered a related bug while using Redux Form. I learned that since React officially switched to Fiber, there have been some changes to higher-level components.

The title of this article, “A Brief Introduction,” is not a lie. I won’t talk about the underlying operation of Fiber (because I haven’t studied it seriously yet). I will only use plain language to explain what Fiber is, what problems it was created to solve, and its impact on React lifecycles.

Read More

Recently, while refactoring a project at my company, I tried some things and found that I didn’t really understand React’s rendering mechanism and when render would be triggered. Later, I found that not only me, but many people were not familiar with the whole mechanism, so I decided to write this article to share my experience.

Actually, it’s not too bad if you don’t know how to optimize, but the worse thing is that you think you’re optimizing, but you’re actually slowing down performance, and the root cause is that you’re not familiar enough with the whole mechanism of React. The “optimized” component is slower! This is serious.

Therefore, this article will cover the following topics:

  1. The difference between Component and PureComponent
  2. The role of shouldComponentUpdate
  3. React’s rendering mechanism
  4. Why use Immutable data structures

To determine how much you understand the above, let’s take a few quizzes right away! Some of them have traps, so please keep your eyes open!

Read More

Previously, I wrote an article to briefly summarize my experience in learning Redux. I still recommend the official documentation because it is super clear.

However, when I was reading the official documentation before, I didn’t fully understand the middleware part and got confused towards the end. This time, I re-read the official documentation on middleware and asynchronous operations, took notes while reading, and finally understood the implementation principle of middleware. As usual, I will share my experience.
Official documentation (Chinese version, but this article has not been translated yet)

The great thing about the official documentation is that it not only teaches you how to use it, but also starts from scratch, so you know why middleware is in its current form.

Read More