preface
Taro’s trip to the app is really exhausting
Outline of the content
In this issue:
Taro v1.3.21 (Taro V1.3.21)
Description:
Taro zaokuai app because of the story is too much, but also because some of the plot is beyond the general front people’s cognition, I dare not say anything. When I have a personal insight into the core of the idea, and the system as a whole, and have the ability to criticize the alignment, I will explain the details. For now, let’s start with the most critical, problematic levels from development to release.
Error “can’t find the file you need to rely on”
Background:
When developed in conjunction with native components, the Taro component calls the native component, which in turn calls the native component or some other JS file. The Taro component is compiled, and the native components called by the Taro component are compiled, but the native components or JS files referenced by the native component are missing.
Analysis:
Taro can only analyze the relevant content of Taro when compiling. There is no in-depth recursive analysis of the referenced native components, so the solution is simple. If the compiler can’t analyze them, just copy all the native content. You won’t compile anyway (note that the Taro component doesn’t need to be copied. Why? Dear, you carefully review. .
Solution:
Copy native fast application components through scripts.
I wrote the copy script, but why is the native app content still not copied? Or is there still a problem after compiling?
Pro, your copy script location needs to be placed before the taro Build –type QuickApp command is executed so that build environment variables are not lost.
Please note that implementing taro build –type QuickApp without –watch is a release build, which will clean up the generated directory space and build again. You can modify Taro’s underlying code as shown below:
Release and Debug are built in different styles
Background:
When you’re happy to finally get the development done and the test passed. Then you hit a formal environment integration test package and find, with horror, that all the page styles are more or less out of order.
Analysis:
The generation style of the Debug development environment is different from that of the release formal environment.
Solution:
1. Temporary quick solution (timely release was required at that time, temporary). Back up the styles generated by the DEBUG environment and directly overwrite the styles generated by the Release environment.
2. Modify taro source code, analysis found that when it was a release environment, style redundancy was removed and csSO library was referenced, but the processing was not so satisfactory. For specific modifications, please refer to the picture below:
Conditional compilation of styles
Background:
Taro has added style conditional compilation to make it easier for you to write style code across styles. But when it comes to conditional style compilation for quick applications, it doesn’t work at all.
Reserved for specified platform:
/* #ifdef %PLATFORM% */ #endif */Copy the codeSpecified platform culling:
/* #ifndef %PLATFORM% */ #endif */Copy the codeThe take-home message: However, we found that conditional style compilation in quickapps was completely ineffective. According to?
Analysis:
Review the source code to find taro’s conditional style compilation, which is written in an NPM package. The core code is as follows:
// postcss-pxtransform
/* #ifdef %PLATFORM% */
// Platform-specific styles
/* #endif */
css.walkComments((comment) = > {
const wordList = comment.text.split("");
// The specified platform is reserved
if (wordList.indexOf("#ifdef") > -1) {
// No specified platform
if (wordList.indexOf(options.platform) === -1) {
let next = comment.next();
while (next) {
if (next.type === "comment" && next.text.trim() === "#endif") {
break;
}
consttemp = next.next(); next.remove(); next = temp; }}}});/* #ifndef %PLATFORM% */
// Platform-specific styles
/* #endif */
css.walkComments((comment) = > {
const wordList = comment.text.split("");
// Specify platform cull
if (wordList.indexOf("#ifndef") > -1) {
// Specify the platform
if (wordList.indexOf(options.platform) > -1) {
let next = comment.next();
while (next) {
if (next.type === "comment" && next.text.trim() === "#endif") {
break;
}
consttemp = next.next(); next.remove(); next = temp; }}}});Copy the codeSolution:
The first step is to add an accelerated application type to postCSS-pxTransform.
Step 2: During taro-CLI construction, remove the original judgment of ignoring the platform and add the corresponding platform parameters as follows
4. Writing is not supporteddisplayparameter
Background:
The display field is used when we need to do some special configuration (title, navigation color, etc.) on some pages. However, Taro has officially stated that these two attributes are not supported for the following reasons:
It can be seen that, compared with the official configuration items supported by Taro, the configuration items supported by Taro are missing the Router and display configurations. This is because these two configurations will be generated directly according to user codes during Taro compilation, and no additional configuration is required.
However, our project is special in that the Taro page co-exists with the native quick application page, so we need to be able to configure the display field independently.
Solution:
Taro- CLI to handle the need to deal with the content, we only need to make simple adjustments (according to the need to do different levels of adjustment). Go straight to the picture:
Note: In the same way that Taro is modified, let Taro support Router configurations, as well as other fields.
The last
This article documents some of the key issues encountered during the first time from development to normal launch. Compatibility with these problems can only be said to be satisfied so that we can go online normally, but there will be many small problems in the development process. We must adjust our own mentality! Adjust your attitude!! Adjust your attitude!!
The way is always more than difficult!