preface

It has been nearly four months since the first React Source Code Analysis (I). Since it is my first time to write about source code parsing, my thinking and writing style are not mature enough. Over the past 100 days, I’ve been reflecting on the shortcomings of these articles based on reader feedback, and I’ve been learning from other writers’ writing methods and ideas. Finally summed up for their own source writing, need to improve the following points:

The problem

1. Too much sample code

This may be a common problem with source code parsing writing. In fact, most people can guess what the internal process is from the lifecycle apis of frameworks like Vue and React. Too much sample code can be boring, and some of the sample code is long and smelly, and you have to add large sections of comments, which seriously depress the reading experience.

2. Analyze a running book

Since code is a running book for computers, parsing can no longer be a running book for people. One of the biggest mistakes with source code parsing is trying to understand the meaning of every line or even every variable, which can end up being less effective. So source code parsing should be in the sense of a high perspective to write, rather than drill, or like a monk chanting dry, word for word.

3. Lack of refinement

When we were in Chinese class in middle and high school, we were always asked what the central idea of this article was. Also, what do authors and readers learn from writing and reading source code parsing? Many source code parsing articles do not tell us, the reader seems to understand something after reading and seem not to understand, a face at a loss.

In response to the above three problems, combined with the existing React source Code Parsing series, I made the following improvements:

To improve the

1. Reduce sample code and use language generalizations and graphics whenever possible

People accept and understand graphics much more than they process and understand language, which is why books like Illustrated HTTP are selling well all over the world. The new React Source Code Resolution does away with a lot of useless code and language descriptions. Instead, it uses mind maps or flowcharts to improve the reading experience and make it easier to understand. Of course, important sections of the source code still need to be shown.

2. Beautify your composition

When doing the necessary code examples, if the code is long, the actual reading experience, whether using the nugget editor or the code screenshots, is not good at the end, especially on mobile. The new React source parsing will use Carbon to display code.

3. Thought refinement

The ultimate function of reading the source code is not to recreate vUE/React, but to learn from the ideas and methods therein, and apply them to the actual business, and finally improve our programming ability. The new React Source Code Parsing will explain the why-and-why at the end of each article, so that readers won’t be wasting their precious time.

3. Summary

The new React Source Code Analysis is still divided into four parts (based on V15), which respectively explain the important concepts in React. The table of contents is as follows:

  • React Source code Parsing (1): Component implementation and Mounting
  • React Source Code Parsing (part 2): Component Types and Lifecycle
  • React Source code Parsing (3): A Detailed explanation of Transactions and Queues
  • React Source code Parsing (4): Event System

Here’s a mind map (best viewed on a MAC) :

Each part of the map is explained in detail in four articles. If there is any problem, readers are welcome to point out and discuss, learning and progress together.

Contact email: [email protected]