Because of the recent use of TARO to write small procedures, out of curiosity, ready to read the source code of TARO.

Directory analysis

First pull the latest Taro source code from the official website, version number is 3.0.18, the source directory is as follows:

The catalogs are nothing special, let’s focus on the core packages in the Packages catalog (as shown below)

These core packages make up Taro and enable the multi-platform build of Taro.

@tarojs/taro

The most common package we used during development was tarojs/taro. We started with the entry file Packages /taro/index.js (see figure below).

From the figure above, we can see that TARO introduces corresponding compilation packages according to different compilation environment variables, thus speeding up compilation and reducing compilation volume.

The compilation package introduces an initNativeAPI initialization function that initializes the native API of the corresponding platform.

The WeChat platform compiles the package

Packages /taro/apis/wx.js: InitNativeAPI (Packages /taro/apis/wx.js)

So let’s take a look at what initNativeAPI does, and basically what initNativeAPI does is it takes a little bit of a second wrapper from the WeChat API, and then turns it into a mount under the Taro object, Developers call the Taro API to call the WeChat official API.

processApis

Let’s start by looking at what the processApis method in the InitNativeAPI does (see figure below).

As you can see from the figure above, Taro first collects three types of methods:

1. 'onAndSynCapis' : Event listening and event synchronization API; 2. 'noPromiseApis' : There are no asynchronous events that return' Promise '. 'Taro' will second encapsulate these events using 'Promise'. 3. 'Otherapis' : Other APIs, such as device, media, platform specific APIs;

For methods not supported on the WeChat side, a warning function is returned (as shown below).

For otherApis, if the last argument is taroComponent, the last argument will be replaced with taroComponent.$scope (as shown below).

For onAndSyncApis and noPromiseApis, there are several different ways to deal with them:

1. When the first parameter is a string, return the result of WeChat API execution (as shown in the figure below).

2. When the method is to jump class function, first remove the opening '/', remove the 'query' part, and use the URL to get the component. If the component exists and contains the 'componentWillPreload' method, 'componentWillPreload' is executed and the result of execution is stored in 'cacheData' for subsequent lifecycle hooks of the component.

3. Create a new 'Promise', wrap the method, reject on success, and return the Promise.

This is what Processapis does, which repackages all the WeChat native APIs and then mounts them in the Taro object.

request

Next, let’s take a look at the network request modification. In addition to the request modification, the AddInterceptor and CleanInterceptors methods are added to perform some additional operations before or after the request is issued. The code is implemented as follows:

  taro.request = link.request.bind(link)
  taro.addInterceptor = link.addInterceptor.bind(link)
  taro.cleanInterceptors = link.cleanInterceptors.bind(link)

To see the implementation of AddInterceptor, you need to find the Link implementation (see Figure 1).

As you can see from the red circles in the figure above, the interceptor that creates the Link instance will be placed at the end of the call Chain, then each interceptor will be executed in turn by Chain, and finally the interceptor that creates the Link instance will be executed.

From the above analysis, it is clear to see the implementation of the interceptor. Now let’s look at the implementation of Request (as shown in the figure below).

As you can see from the figure above, the main requirement of the request implementation is to double encapsulate the native request method with a Promise, with no more special handling.

After analysis, we found that Taro encapsulates network requests, giving it the characteristics of an interceptor and a more friendly way to invoke Promise.

other

The next three are all global methods of the WeChat applet, mounted directly (as shown below)

Next is the pixel conversion function, which mainly converts pixels to the corresponding RPX (as shown below).

This is followed by canIUseWebp, which is a way of determining whether or not you can use a WebP image (see below).

As you can see from the figure below, only Android and developer tools support WebP images, so use WebP images with caution.

Finally, mount the cloud development SDK of WeChat in the Taro. Cloud object to complete the mount (as shown below).

summary

So far, @tarojs/taro has been resolved to complete, this part of the source code implementation is relatively concise, as the Taro source reading series introductory or quite good ~

One last thing

If you’ve already seen this, I hope you’ll like it before you go

Your thumb up is the greatest encouragement to the author, and can also let more people see this article!

If you found this article helpful, please help to light up Star on GitHub.