Recently, I used Taro to write a small program. Out of curiosity, I plan to read Taro’s source code.
Directory analysis
First, download the latest Taro source code (version 3.0.18) from the official website. The source directory is as follows:
There’s nothing special about directories. Let’s focus on the core packages in the Packages directory (see figure below)
These core packages make up Taro and enable its multi-platform build.
@tarojs/taro
The package we use most frequently during development is tarojs/taro. We start with the entry files Tarojs /taro/index.js (see figure below).
As can be seen from the above figure, Taro has introduced corresponding compilation packages according to different compilation environment variables to speed up compilation and reduce compilation volume.
The compilation package introduces an initNativeAPI initialization function that initializes the platform’s native API.
Compile package for wechat platform
Here we take the most popular wechat applets for example. Open the packages/taro/apis/wx.js file and find the exported initativeAPI function (as shown below).
Let’s analyze what initNativeApi does. In general, what initNativeApi does is to perform some secondary encapsulation of wechat API, and then convert it into an Taro object. Developers can call the official wechat API by calling Taro’s API.
processApis
Let’s start by looking at what the processApis method in initativeapi does (figure below).
As can be seen from the above picture, Taro first collects three methods:
1. 'onAndSyncApis' : event listening and synchronization event API; 2. 'noPromiseApis' : asynchronous events that do not return' promises' and 'Taro' will encapsulate these events using 'promises'. 3. 'otherApis' : otherApis, such as device, media, and platform-specific apis;Copy the code
For methods not supported by wechat, a warning function will be returned (as shown below).
For Maida, if the last parameter is TaroComponent, the last parameter is replaced with TaroComponent.$scope (figure below).
There are several different ways to handle onAndSyncApis and noPromiseApis:
1. When the first parameter is a string, return the result of wechat API execution (as shown below)Copy the code
2. When the method is a jump class function, remove the beginning '/' and the 'query' part first, and use the URL to obtain the component. If a component exists and contains the 'componentWillPreload' method, 'componentWillPreload' is executed and the execution result is stored in 'cacheData' for subsequent component lifecycle hooks.Copy the code
3. Create a 'Promise', encapsulate the method, resolve on success, reject on failure, and return the 'Promise'.Copy the code
This is what processApis does, which rewraps all the wechat native apis and then mounts them in an Taro object.
request
Let’s take a look at the revamp of the network request. In addition to the revamp of the Request, we have added addInterceptor and cleanInterceptors methods to do additional operations before or after the request is issued. The code implementation is as follows:
taro.request = link.request.bind(link)
taro.addInterceptor = link.addInterceptor.bind(link)
taro.cleanInterceptors = link.cleanInterceptors.bind(link)
Copy the code
To understand the addInterceptor implementation, you need to find the Link implementation.
As you can see from the red circle in the figure above, the interceptor used to create the Link instance is placed last in the invocation Chain, and then each interceptor is executed in sequence by the Chain, and finally the interceptor used to create the Link instance.
The implementation of the interceptor is clear from the above analysis. Now let’s take a look at the implementation of the Request (figure below).
As you can see from the figure above, the main requirement of the Request implementation is to rewrap the native Request method with Promise, with no more special handling.
Based on our analysis, we found that Taro’s encapsulation of web requests gives it the characteristics of an interceptor and a friendlier way to invoke promises.
other
The next three are the global methods of wechat applets, mounted directly (as shown below)
Next comes the pixel conversion function, which converts pixels to the corresponding RPX (as shown below).
It was followed by canIUseWebp, which means to determine whether images in webp format can be used (see below)
As you can see from the following figure, webP images are only supported by Android platforms and developer tools. Therefore, use webP images with caution.
The last step is to mount wechat’s cloud development SDK into the taro.cloud object and complete the mount (as shown below).
summary
Here, @tarojs/taro has been parsing completed, the implementation of this part of the source code is relatively concise, as the source code reading series is quite good ~
One last thing
If you’ve already seen it, please give it a thumbs up
Your likes are the greatest encouragement to the author, and can also let more people see this article!
If you find this article helpful, please help to light up the star on Github.