Taro was originally designed to unify cross-platform development and has tried its best to smooth out the differences between multiple ends through runtime frameworks, components, and APIs, but there are still some differences between different platforms that cannot be eliminated, so in order to better realize cross-platform development, Taro provides the following solutions
Note: The way environment variables are used in the code, reference
Taro provides some built-in environment variables at compile time to help the user do some special handling
Used to determine the current compilation type, currently there are
quickapp eight values, This variable can be used to write code for different environments, and when compiling the code that does not belong to the current compile type will be removed and only the code under the current compile type will be kept, for example, if you want to refer to different resources in the WeChat mini-program and H5 respectively
It can also be used in JSX to determine which components to load on different ends.
1.2.17 start support
The built-in environment variables can solve most of the cross-end problems, but it will fill the code with logic judgment code, which affects the maintainability of the code, and also makes the code more and more ugly. To solve this problem, since
1.2.17, Taro provides another way of cross-end development as a supplement.
Developers can address features that differ across ends by using multiple platform files with a unified interface. For a feature, if there are differences between multiple ends, developers can modify the file into the naming form of
original file name + end type, so that the file code of different ends keeps a unified interface to the outside world, while the reference is still
import the file with the original file name. Taro will change the loaded file to a file with the file name of the corresponding end type at compilation time, so as to achieve the purpose of loading the corresponding file for different ends.
The end type corresponds to the value of
There are usually two usage scenarios.
If there is a
Test component that exists in three different versions - WeChat mini-program, Baidu smart-program and H5 - then the code can be organized like this
test.js file, which is the default form of the
Test component, is compiled to a version that is used outside of the WeChat mini-program, Baidu smart-program and H5
test.h5.js file, which is the H5 version of the
test.weapp.js file, which is the WeChat mini-program version of the
test.swan.js file, which is the Baidu smart-program version of the
test.qq.js file, which is the QQ mini-program version of the
test.quickapp.js file, which is the quick app version of the
The four files, which expose a unified interface to the outside world, accept consistent parameters, but only have internal code implementations for their respective platforms
When we use the
Test component, the reference remains the same as before, the
import is a file name without the end type, and the end type suffix is automatically recognized and added at compile time
Similar to the multiple platform component, if there is a need to write different script logic code for different ends, we can handle it similarly, the only principle to follow is to keep the external interface of the multiple platform file consistent.
For example, we use
Taro.setNavigationBarTitle to set the page title on WeChat mini-program, and H5 uses
document.title, then you can encapsulate a
setTitle method to smooth out the difference between the two platforms.
set_title.h5.js,with the following code
set_title.weapp.js，with the following code
When called, the following is used
There are three key points of use for this cross-platform compatible writeup of the unified interface's multi-terminal files
- The corresponding files on different ends must have a unified interface and a unified call method
- It is better to have a platform-independent default file, so that there will be no error when using ts
- When referring to a file, only the default file name should be written, not the file suffix.
1.3.11 Start of support
Depending on the environment, different
pages are returned, which can be written like this
The multiple platform files in Taro 3 are parsed by the MultiPlatformPlugin plugin.
It is an enhanced-resolve plugin, which is loaded internally by taro by default. However, the plugin does not resolve files in node_modules by default.
If we have an npm package called @taro-mobile and we need to parse the multiple platform files in it, we can change the configuration of the MultiPlatformPlugin in the taro configuration file like this:
The Taro 3 RN side does not use webpack, so it can't be consistent with the other side, so a configuration support has to be added here.