Write in front
Recently, I took time to read the source code of vue-next/runtime-core one after another. During this period, I sorted out a lot of notes, but they were all fragmented. I originally wanted to sort it out and write it into an article to share it, but I feel that the final result can only be analytical articles with huge lengths. Even if I comment on the source code line by line, the reading experience will be very poor, because everyone has different habits and different ideas. As the saying goes, throwing bricks and attracting jade, so I think writing a guide as this brick should be enough. I hope it can help readers who want to read the source code but feel that they have no idea how to start.
On the other hand, it can be considered a pit for yourself, because many of the content involved in this article are definitely not clear in a few words, which means that other articles must be written to fill these gaps later. I will sort out the highly cohesive modules as much as possible and then share them, trying to avoid falling into the situation of listing codes, so as to improve the quality of the article.
I hosted the reading notes on Yuqi, and I can read them without any confusion.here。
Preparation
If you want to do a good job, you must first sharpen your tools. You need to look at the source code. It is definitely not possible to use the writing board to read it (of course, it is not ruled out that great people are not ruled out). All you need is an editor that supports code jumping. I use VSCode. Of course, it is OK if you use VIM or Sublime.
Also some reserve knowledge is needed:
- Since it is the code that reads vue-next and is the version of pre-alpha, this requires you to have a certain understanding of previous vue. If it was the first time I came into contact with it, I think the meaning of reading source code is not very important.
- You need to master the basic skills and processes of debug. There are two benefits to viewing the code through debugging.
- The debug process has a clear call stack record
- Variables under various scopes are clear at a glance
- You need to have a certain degree of mastery of typescript, at least you can know the concepts of interface, enum, etc.
How to read
There are generally three ways:
- Watch it directly
- Executable code through unit test
- Executable code written by yourself
The second method is recommended here, because unit testing is maintained by the official team and the quality is definitely guaranteed. Secondly, unit testing is generally simple and has comments, which is conducive to our understanding of the code.
Since vue-next uses jest for unit testing, you can install the Jest plug-in in vscode. It supports in-line debug lenses for quick entry, making it convenient to directly debug a certain unit test.
However, be careful to configure a custom option:
"": [ "fail", "unknown", "pass", // Pay attention here]
The "pass" here means that debug lenses will be displayed above even if the unit test passes. By default, if the unit test case passes, the debug lenses logo will not be displayed.
Module function summary
There are multiple files in the runtime-core directory, and I will consider each file as a submodule for the time being. The code quality of vue is quite good, and the coupling between modules is not particularly high. Because of this, basically each module has its own corresponding unit test file.
When I was watching, I basically looked at the unit tests of these modules one by one, and then during the debugging process, I would actively jump some code to see the specific implementation details. Below is a summary and summary of the functions of all modules in the file directory under the current latest code.
There are some more independent modules I haven't finished reading yet, but they will not affect the overall source code reading process. I will just come back to supplement these todo only when I conduct separate research on these independent modules in the future.
Public API Related
The modules that implement public APIs are named in the format apixxx, as follows:
- : There are 3 more important interfaces that need to be looked at, App, AppConfig and AppContext. If you are familiar with vue2, it will be easy to understand. createApp is a factory method that returns an object that complies with the App interface constraints. Its internal method interacts with an object that complies with the AppContext interface constraints.
- : This file contains multiple overloaded declarations for the createComponent function signature, and its purpose should be to help ts provide better type inference to improve the development experience.
- : The implementation logic of component dependency injection feature. The implementation method is very simple. It directly interacts with the currentInstance variable exposed in the component file to implement inheritance, assignment, and value acquisition logic.
- : New component declaration cycle hooks, mainly look at the injectHook method. The target here points to currentInstance by default, and then caches a callback logic in the declaration cycle callback function array of the currentInstance instance
- : It contains the implementation logic for how component parses options. The code is long and complex, and the coupling is higher than that of several other files. But in fact, there is no need to read all the code inside it directly, because the parsing logic of each paragraph in options is independent of each other, so you can view the parsing logic inside it separately for a certain option. I have only read data and lifecycle at present.
- : It is a reexport of the API in the reactivity package, nothing extra
- : I haven't read it carefully yet, but according to the name, it can be seen that it is an API related to watch. I took a rough look and found that the coupling is relatively low, so I can watch it later
Component related
- : It mainly includes logic of how to create an internal component instance. The code is relatively long, but if you click in, you will find that it is actually calling the exposed API of other modules, and its logic is relatively simple. It should be noted that this file will expose a pair of setCurrentInstance and getCurrentInstance methods to maintain the pointer of the currentInstance variable, and it will be used in other modules.
- : Declare the implementation logic of render proxy. This proxy is mainly responsible for how external interaction with internal component instances. You can regard it as an external component instance
- : Mainly looking at resolveProps, implementing how to parse various forms of props
- : It mainly looks at resolveChildren, which implements how to parse various forms of children nodes
- : Some rendering components' util methods, you can understand the meaning of each method by name
- : This has a low coupling degree with other files, and can be understood as a VNode renderer. As long as it implements its interface, it can be rendered in any context, such as a mini program, native, canvas or memory environment. Regarding how to write a renderer, just look at the code of runtime-test or runtime-dom
- : Instructions-related internal API, current code version, this part may be many todo, so you can come back and take a look in the future
other
- : Error handling related, haven't read it carefully yet
- : The job scheduler is related, I haven't read it carefully yet
- : Enumeration declarations and constants of the component itself and children type
- : suspension related, I haven't read it yet. For the relevant logic of suspension in other files, I completely understand it according to the relevant concepts in react, and I have not encountered any obstacles for the time being
- : Warning related, most of them are some util methods, just understand their meaning by name
Recommended reading order
I just talk about my own reading order, which I think is more in line with cognitive habits:
- First look at the codes about vdom and other vdom to learn about the data structure of the new VNode
- Then look at how the mount process associates VNode with the rendering context. This process will naturally involve various contents, just look at them one by one.
- Since we have looked at public APIs before, if you need to understand the implementation details, you need to look at it further, which mainly includes the data structure and creation process of internal component instances. Similarly, you can read the breakpoints one by one line by one.
- For some analysis and tool methods, you can put them at the end and look at the implementation details. There is no need to explore the breaking point process, because the names of some methods can clearly explain what the logic behind it is.
During this period, you will encounter codes such as suspension and lifecycle. This type of code can also be read as separate content. When you first read, you can not be too obsessed with the details. When you have a rough understanding of the overall process, you will look much clearer. Later, I will organize an article to introduce how this is implemented.
Written at the end
Although the code of vue-next is still in its early stages, the overall reading experience is still good, the structure is clear and readable, and some key modules are also explained with comments. The only disadvantage is that many places still use the as keyword to make type assertions. I think there may be a better way to implement type inference in these places.
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.