preface
Recently received a project requirement, is to make a set of pages, not only applied in the small program environment, but also applied in H5, and compatible with both ends of the original logic unchanged. Finally, after our investigation and sorting, we decided to use the latest version of Taro3 to achieve the appeal of multi-terminal unified development.
So why do we choose Taro? I think they have the following advantages
- Developed by JINGdong Concave Laboratory,
High frame stability
- Compared to Taro1 and Taro2, Taro3 had a happier development experience, as well as a React or Vue web experience
- Compared to the UniApp framework, Taro
Flexibility is high
,Strong configurability
And there are more development frameworks to choose from - Taro
Community activity is high
Abundant material storage around
Project (
1. Multi-terminal development through Taro3, how to achieve compatibility of the code, can be adapted to H5 and small programs, and ensure smooth start in multi-terminal.
2. Since the native applet end has its own code logic, the H5 end has its own code logic, and the logic at both ends is unrelated. How to achieve a set of code development out of the page, at the same time insert H5 or small program, can be compatible with both ends of the original logic process.
3. Build a set of general framework, which can quickly and efficiently access other multi-terminal pages to achieve cost reduction and efficiency improvement.
The evolution of the Taro structure
Before starting development, I think it is important to understand Taro’s evolution of architecture. Do a basic understanding.
Taro 1/2 (recompile)
In Taro1 and Taro2 phases, the compile phase plays an important part. To put it simply, the Taro code is mainly compiled into codes that can be run by each end (various small programs, RN, H5, etc.). Through lightweight runtime adaptation, Taro’s component library, runtime framework and API are used to smooth out the differences to solve the multi-end differences.
Taro3 (Rerun)
No matter what framework is used for development, React, Vue or jQuery, the final code will call the BOM/DOM API of the browser after running, such as: CreateElement, appendChild, removeChild, etc. On the applet side we can emulate the DOM and BOM APIS to make the front-end framework run directly in the applet environment.
Therefore, the differences in life cycle, component library, API and routing can still be smoothen by defining unified standards (such as standard component library and standard API), and each end is responsible for its own implementation.
Taro V3.1 Open Architecture
Taro’s core maintenance platform is only 6 (wechat, Alipay, Baidu, Toutiao, QQ, JINGdong mini program), so users often need to timely support and maintenance of other platforms. Because of the single-platform compatibility code, the compilation and run-time parts are difficult to change, and the community is difficult to contribute. Therefore, an open framework has been created to extend Taro’s terminal platform support capabilities through plug-ins:
- Plug-in developers can write a terminal platform plug-in without modifying the Taro core library code.
- Plug-in users simply install and configure the terminal platform plug-in to compile code to the specified platform.
- Developers can inherit existing end-platform plug-ins and customize the platform adaptation logic.
Taro has made adjustments based on the open architecture, packaging the six built-in supported platforms into plug-ins, which will be loaded by CLI by default. In the process of encapsulation, it is also to retrieve the latest components and APIS of each small program, and update and support them, and align the latest capabilities of each small program.
Project development and construction process
After a brief understanding of the evolution of the architecture, let’s start to build the project
1. Taro3 installation
CLI Tool Installation
yarn global add @tarojs/cli
Copy the code
Project initialization
2. Compare the native applet with the Taro directory
First of all, let’s compare the differences between the two directory structures. In fact, the two structures are not too different, and it is easy to understand and get started.
3. Package operation analysis of H5 and small programs
1) Scripts script configuration
Let’s look at the scripts after the project is initialized:
Use the Taro build command to compile the Taro code into different parts of the code:
Taro builds in dev and build modes:
- Dev mode (adding the –watch parameter) will listen for file changes.
- Build mode (with the –watch parameter removed) will not listen for file changes and will compress the code.
- The file generated in dev mode is large. Set environment variables
NODE_ENV
为production
You can turn on compression for easy preview, but it will slow down compilation.
"build:weapp": "taro build --type weapp".// Wechat applets
"build:swan": "taro build --type swan".// Baidu small program
"build:alipay": "taro build --type alipay".// Alipay applet
"build:tt": "taro build --type tt".// Bytedance applet
"build:h5": "taro build --type h5".// H5
"build:rn": "taro build --type rn".// React Native
"build:qq": "taro build --type qq".// qq small program
"build:jd": "taro build --type jd".// Jingdong mini program
"build:quickapp": "taro build --type quickapp".// Fast application
Copy the code
2) How to support compiling other applets
As mentioned above, Taro has adapted its architecture to an open architecture in order to make it easier to compile other small programs. In addition, it has extended the support capability of Taro’s terminal platform through plug-ins. Here is an example of enterprise wechat small programs:
Installing a plug-in
yarn add @tarojs/plugin-platform-weapp-qy
Copy the code
Configure the plug-in
// config/index.js
config = {
// ...
plugins: [
'@tarojs/plugin-platform-weapp-qy']}Copy the code
Package compiled
npm run build:qywx
Copy the code
Note:
Taro V3.1 + start support
3) How to preview the package from taro
The H5 package preview is no different from our usual way, so how does the applet operate? Here is an example of wechat applets:
At this time, download and open the wechat developer tool, and then import the dist package in the root directory of the project. You can see the interface:
4. Some details of Taro3 development
We recommend you to briefly review the official documentation of Taro to learn about the use of some official apis and component libraries. We will not list them here. The following author will directly talk about some of the development process encountered in some of the pits and I think the more important part, to avoid some detours.
1) Use routes
The routing used in Taro3 is different from previous versions. Both project input parameters and page entry parameters are obtained using getCurrentInstance().router, as shown below.
import Taro, { getCurrentInstance } from "@tarojs/taro";
import React, { Component } from 'react'
export default class Index extends Component {
componentDidMount () {
console.log(getCurrentInstance().router.params)
}
}
Copy the code
2) Package the new version number
In the h5 compilation package, if you want to increase the version number, you need to configure the prod.js file in the config directory, which will expose a h5 specific configuration for everyone to use. Here are some examples of setting the output directory of the parse file and extending the Output option of Webpack:
var config = require('.. /package.json');
var path = require('path');
module.exports = {
env: {
NODE_ENV: '"production"'
},
defineConstants: {},mini: {},
h5: {
publicPath:config.publicPath+config.version,
output: {
path: path.resolve(__dirname, `.. /dist/${config.version}`),},/** * If the H5 side is too large after compilation, you can use the webpack-bundle-Analyzer plug-in to analyze the package volume. * Reference code is as follows: * webpackChain (chain) { * chain.plugin('analyzer') * .use(require('webpack-bundle-analyzer').BundleAnalyzerPlugin, []) *} * /}}Copy the code
3) Interface request
Taro encapsulates its own API for web requests. For example, I use async/await:
const options = {
method: requestType, // "GET" or "POST"
url,
data: param,
credentials: "include" as credentialsType,
timeout: 1000 * 30.header: h,
};
const res = await Taro.request(options)
Copy the code
Note:
In the applets environment, the interface URL request must be HTTPS
Project difficulties
For this demand, the most important thing to do is how to use Taro3 to develop a set of pages, and at the same time compatible with both ends of the process (wechat small program end and H5 end). In addition, the dist directory packaged in the micro channel applet environment was inserted into the native applet to achieve mixed development.
1. Compatible with process construction at both ends
Here we first need to encapsulate functions to distinguish between different environments, encapsulated in the utils directory.
const Utils = {
isH5() {
return process.env.TARO_ENV === "h5";
},
isWeapp() {
return process.env.TARO_ENV === 'weapp'; }};export default Utils;
Copy the code
This allows us to process h5 logic during development, such as clicking the submit button to distinguish between h5 environments. Distinguish the logic of micro channel applets, then process the logic of micro channel applets.
2. Mixed development
Now we are faced with such a scenario, that is, in the context of the Taro project framework, we distinguish the micro channel applet. Now we need to jump to a page of the native applet, such as invoking the native login to get through, so how should we achieve it?
Let’s think about it. Even if you develop only one page, the package dist that the applet produces is the entire applet. Now that we want to insert the outgoing package into the native applet, we need to package it as a separate package.
1) Package in mixed mode
Fortunately, Taro3 officially offers hybrid development, which allows native applet projects and packaged projects to be blended, through the –blended command.
taro build --type weapp --blended
Copy the code
At this point, the taroApp will be exposed in the packaged app.js for us to call its life cycle on the native applet’s app.js page.
However, there is a problem. When implementing our native applet project, we pre-initialize some runtime logic by referring to the entry file importing the Taro project in the native project app.js. Therefore, we need to ensure that the logic in the Taro project’s app.js file will be executed first. So it’s just the bombed command, so it’s just going to work with the main package pages, and it’s not going to work with the blended command.
2) Solve subcontracting development by introducing @tarojs/plugin-indie
Install first
yarn add --dev @tarojs/plugin-indie
Copy the code
Then introduce the plug-in configuration
// config/index.js
const config = {
// ...
plugins: [
'@tarojs/plugin-indie'
]
// ...
}
Copy the code
To put it simply, when compiling the code, adjust the directory introduced by require for the JS chunk file under the page and add the sourceMap mapping of the corresponding module. In this way, when visiting our taro subcontracting page, we can achieve priority execution.
3) handwritten @tarojs/ plugin-MV plug-in, automatic moving packed files
After handling the package process of subcontracting, we created a page folder taroMini under the Pages page of the native applet to import the subcontracting pages packaged under our Taro project. We then introduce the subcontracted path configuration in the native applet’s app.json.
{
"subPackages": [{"root": "pages/taroMini/pages/riskControlAnswer"."pages": [
"index"]]}}Copy the code
Now we manually package taro out of the folder, drag the native small program taroMini directory can run our page. As shown in figure:
At this point, we need to think again, each time the packaged dist folder, should be manually dragged into the native applet project, is there an automatic way, let itself move. Here we begin to write a plugin by hand:
// plugin/index.js
const fs = require('fs-extra')
const path = require('path')
export default (ctx, options) => {
ctx.onBuildFinish(() = > {
const blended = ctx.runOpts.blended || ctx.runOpts.options.blended
if(! blended)return
console.log('Compile complete! ')
const rootPath = path.resolve(__dirname, '.. /.. ')
const miniappPath = path.join(rootPath, 'jdc_wx_ecard')
const outputPath = path.resolve(__dirname, '.. /dist')
// taroMini is your routing folder under the jd.com applets project
const destPath = path.join(miniappPath, `./pages/taroMini`)
console.log('outputPath', outputPath)
console.log('destPath', destPath)
if (fs.existsSync(destPath)) {
fs.removeSync(destPath)
}
fs.copySync(outputPath, destPath)
console.log('Copy over! ')})}Copy the code
In fact, take a closer look at the code, the idea is to carry out a folder automatically move script. We then introduced this plugin, which we had written by hand, into our Taro project
// config/index.js
const config = {
// ...
plugins: [
'@tarojs/plugin-indie',
path.join(process.cwd(), '/plugin/index.js')]// ...
}
Copy the code
4) application
As mentioned above, jump to a page of the native app in the Taro project and you will be able to write normally in our local Taro project (well distinguished is the wechat app environment).
const { orderId } = param;
const fromPageType = "";
const returnPage = encodeURIComponent(`/pages/taroMini/pages/riskControlAnswer/index? orderId=${orderId}`);
const url = `/pages/login/index/index? returnPage=${returnPage}&pageType=${fromPageType}&noWXinfo=1`;
Taro.redirectTo({ url });
Copy the code
Other functions that call native applets can now be developed as normal.
Project summary
In this way, we have realized some of the requirements we mentioned at the beginning, realizing the mixed development of the Native applet Taro project, and also realizing the automation between the Taro project side and the native applet side. In fact, there are still a lot of places worth exploring for Taro3 to dig deeply. I will share with you later if I have the opportunity. Today, I will go home from work and lie down
The resources
Nervjs. Making. IO/taro/docs/R…
Mp.weixin.qq.com/s?__biz=MzU…
Juejin. Cn/team / 693052…