Daniel Ant Financial · Data Experience Technology team
At present there are a lot of online “XX source analysis” such articles, but the scope of these articles source analysis is limited, sometimes the content is not the most concerned about readers. I have also noticed that the source code is constantly updated and the source code written in the article is often outdated. Because of these problems, many students like to see their own source code, their own hands, ample food and clothing.
This article focuses on some tips for reading the source code of large open source front-end projects such as React, Vue, Webpack, and Babel. The purpose is to let everyone in the need to read the source code to solve the problem, you can quickly locate the code you want to see. Teaching people how to fish is better than teaching people how to fish. Hopefully, this blog will give you an idea of where to start when reading the source code for large front-end projects. When you come across curious questions later, explore them on your own.
Problem driven – Don’t look at source code just for the sake of looking at it
What is the purpose of looking at the source code?
My personal opinion is that the source code is to solve the problem. There’s nothing very special about the source code for open source projects, it’s just plain old code. The code is generally large in magnitude, and if you want to learn from the source code, browsing through Codebase is like looking for a needle in a haystack.
However, if you want to look at the source code with a question, such as the React composite event system, to understand what happens before and after the React setState, or to understand the principles of the Webpack plugin system. Or you may have encountered a bug that you suspect is a framework/tool problem. In such cases, with a specific goal to look at the source, it will be targeted.
Look at the latest version of the source code
One of the things I’ve seen before is that you start looking at the source code from the first COMMIT of your project. If you want to solve the framework/tool confusion from the previous article, look at the version of the framework/tool being used in your current project.
If you want to learn the source code, I also recommend looking at the latest source code. Because a project is constantly iterating and refactoring. It can be a complete rewrite between versions. Such as Vue 2.x and React 16. Refactoring led to some changes in the code architecture, Vue 2.x introduced Vritual DOM, and the Pull + Push data change detection method made the whole code structure clearer, so the 2.x code is actually easier to read than 1.x. React 16 rewrites the Reconciler to introduce the concept of Fiber, and the entire code warehouse structure is clearer, so it is more recommended reading.
precondition
Look at the source code how to look, of course, not a shuttle.
You need to have a basic understanding of how the project works before looking at the source code. The principle is what are the components of the project and the steps of the process to reach the final output. In these processes, what are the mainstream schemes in the industry?
For example, the front-end View layer framework, to render the UI, components need to go through mount, render, etc. A data-driven front-end framework, after Mounted, enters a loop that updates the UI when user interactions trigger component data changes. There are two methods of data detection: Push and Pull. The rendering UI can be a full string template replacement or a differential DOM update based on the Virtual DOM.
Some of the tools on the front end, Webpack and Babel, are plugin-based. The basic workflow is to read the file, parse the code into an AST, call a plug-in to transform the AST, and finally generate the code. To understand how Webpack works, know that Webpack is based on a module system called Tapable.
So how do we know that? To learn more, check out the XXX source Code Parsing series on various websites and blogs. Through these articles, we can get a general idea of how the framework/tool works.
Local build
But ultimately we’ll have to go straight to the source code. The first step for me to really look at the source code is to clone the project repository locally. Then follow the build guide on the project README to build locally.
If it is a front-end framework, we can directly import the umD bundle from the native build in THE HTML (remember to use the development build, otherwise the code will be compressed and unreadable), and then write a simple demo that will import the native build. If it is a nodejs-based tool, we can use NPM link to link the tool’s commands locally. You can also look directly at the package.json entry file for your project and run that file directly from Node.
It’s important to note that large open source projects usually have a Contribution Guide, which aims to make it easier for developers who want to contribute code to get started. That’s how to build code locally.
Take React as an example, the React Contributing Guide included the Development Workflow section. It contained this passage:
The easiest way to try your changes is to run yarn build core,dom –type=UMD and then open fixtures/packaging/babel-standalone/dev.html. This file already uses react.development.js from the build folder so it will pick up your changes.
Fixtures /packaging/babel-standalone/dev.html in the React repository is a handy demo page. This is where we can quickly see our local changes to the code.
Try adding a log to the project entry file to see if it is visible on the console/terminal. Congratulations, you can play with the project now if you like!
Clear the directory structure
Before looking at the specific code, we need to clarify the directory structure of the project so that we can quickly know where to find the code for the relevant functions.
Let’s look at the React directory structure. React is a monorepo. That is, a warehouse contains multiple sub-warehouses. We can see a number of individual packages in the Packages directory:
After React 16, the React code is divided into React Core, Renderer, and Reconciler parts. This is because the React design allows us to separate the Renderer from the React Core, which maps data to the UI Reconciler, and the Renderer, which renders the Vritual DOM to various terminals. React Core contains React class definitions and some top-level apis. Most of the logic for the render and View layer Diff is in Reconciler and Renderer.
Babel is also a monorepo. The core code of Babel is the babel-core package, which opens up the interface so that we can customize the Visitor to be called when the AST transforms. So there are a lot of plug-ins in Babel’s repository, and it’s these plug-ins that actually do the syntax conversion, not Babel-Core itself.
Vuejs code is typical, with the core code in the SRC directory, divided by functional modules. Since Vue also supports multi-platform rendering, platform-related code is put into the platform folder. The core folder is the core code of Vue, and compiler is the template compiler of Vue, which compiles the HTML-style template into render function.
Webpack, like Babel, is a plug-in – based system. The main source for Webpack is in the lib directory, where webpack.js is the entry file.
The directory structure of a new open source project should be understood.
If the project is a monorePO, first we need to find the core package and then look inside the code.
If the project is not monorepo, generally speaking, if the project is a CLI tool, the bin directory is the command line interface related entry file, lib or SRC is the tool’s core code. If the project is a front-end View layer framework, the directory structure is similar to Vue.
As proof, take a look at the directory structure of the packaging tool Parcel and the front-end View layer library Moon. The directory structure is often the same thing, look at a few projects to become familiar with.
Debugger && Global search method
Now that we’ve run the local build and know the directory structure, we’re ready to look at the source code! As I said, we’re going to be problem driven, so I’m going to use the question of what happens before and after React calls setState as an example.
We can make a break point at setState. So first we have to figure out where setState is. This is where preparation comes in handy. We know that the React common API is under the React package. We’re going to search globally in that package. We found that the API is defined in the file SRC/reactBaseclasses.js.
So let’s make a break point here:
Component.prototype.setState = function(partialState, callback) {
invariant(
typeof partialState === 'object' ||
typeof partialState === 'function' ||
partialState == null,
'setState(...) : takes an object of state variables to update or a ' +
'function which returns an object of state variables.',); debugger; this.updater.enqueueSetState(this, partialState, callback,'setState');
};
Copy the codeThen run the demo page of the React build and have the component trigger setState. We can see the breakpoint in Devtool.
We went into this. Updater. EnqueueSetState this call, came to the enqueueSetState ReactFiberClassComponent this function, The enqueueUpdate and scheduleWork functions are called, and if we want to drill into the process after setState, we just need to click again
To see what happens before setState, we just need to look at the call stack to the right of Devtool:
Clicking on each frame jumps to the corresponding function and restores the current context.
Together with the step-by-step code debugging, we can see the framework’s function call stack. For each important function, we can search the source code in the repository for further research.
The Node tool is similarly debuggable by running the Node command with the –inspect parameter. For details, see the Debugging Node.js with Chrome DevTools blog.
Step debugging is well known, but it’s where you break it that matters. After we are familiar with the principle of the framework, we can break on the key link of the framework, such as the front-end View layer framework declaration cycle hook and render method, Node tool plug-in function, these codes are the necessary place for the framework to run, is a good entry point.
If you want to know about a particular problem, you can just interrupt where you think the problem is. And then run the source code, and figure out how to get the code to run there. We can see local variables and so on at breakpoints to help locate the problem.
Resources from the development team
In fact, the development team of open source project is also committed to let more people participate in the project, lower the threshold of the project. So we can actually find a lot of resources online from the development team. These resources help us understand the rationale for the project.
Focus on core Developers
Each project has a few core developers, like React’s Dan Abramov, Andrew Clark, and Sebastian Markbage. Tobias Koppers and Sean Larkin of Webpack. Evan You from Vue. We can follow them on Twitter to keep up with the project.
Follow the official blog and video of the presentation
If we follow the core developers above, they often post blogs or videos about the source code/project philosophy.
React’s official blog has a number of blog posts related to project development recently.
- Behind the Scenes: Improving the Repository Infrastructure This article introduces the React project Repository Infrastructure.
- Sneak Peek: Beyond React 16
Andrew Clark started by writing an introduction to the Fiber architecture. Dan Abramov’s recent JSConf introduction to some new features in the future of React – Beyond React 16. The React blog Sneak Peek: Beyond React 16 is also an introduction to this Talk.
Evan You’s Talk on front-end framework data change detection principles. The Vue documentation also has a section on Reactivity in Depth.
Sean Larkin’s Everything is a Plugin! Mastering Webpack from the inside Out Introduces Tapable, the core component of Webpack.
James Kyle’s How to Build a Compiler gives us an idea of the basic flow of Babel’s translated code.
Write in the last
The core point of this article is that the purpose of looking at source code is to solve a problem. We encourage you to run the source code of large projects locally, play with it and study it yourself. Because the source code is ordinary code, and there are not too many thresholds. The only barrier may be the information asymmetry between the author of an open source project and the average developer, who does not have enough knowledge of the project’s rationale and directory structure.
Getting resources from developers and reading source code analysis articles in the community will help us understand the principles of the project and lay the foundation for further source code analysis.
If you are interested in our team, you can follow our column, follow Github or send your resume to ‘tao.qit####alibaba-inc.com’.replace(‘####’, ‘@’)
Original address: github.com/ProtoTeam/b…