Taro cross-terminal solution for Ctrip’s mini-program ecosystem

​Author｜Ctrip's front-end framework team provides excellent Web solutions for Ctrip Group's various business lines. Currently, it focuses on: exploring the next-generation R&D model, upgrading the Rust build tool chain, developing Serverless application frameworks, developing online document systems, building low-code platforms, and exploring aging-friendly and barrier-free environments.

I. Summary

As the types of mini-program platforms connected to Ctrip increase, the front-end needs to be responsible for more and more terminals, and the R&D costs also increase exponentially. In order to meet the demand of running one set of code on multiple terminals, Ctrip's mini-program framework has been continuously adjusted and upgraded, and gradually formed the Ctrip Taro cross-terminal solution.

II. Background

2.1 Current Status of Mini Programs

In recent years, the industry has launched a variety of mini-program platforms. Each mini-program platform provides an exclusive native mini-program DSL. There are more or less some differences between these DSLs, which means that the code written using a certain type of mini-program DSL cannot be directly reused on other mini-program platforms, causing the development and maintenance costs to increase exponentially.

2.2 Business Status

Currently, the mini-program business supported by Ctrip involves multiple mini-program platforms. If all are developed using only the platform's own DSL, developers need to develop and maintain at least 5 active versions at the same time, which is a heavy development task and difficult to maintain the code. In addition, for each new mini-program entry, developers must rewrite the original business logic, which not only repeats the work content, but also seriously affects the speed of business implementation. For this reason, the demand for running one set of code on multiple terminals is imminent.

It is worth noting that Ctrip has already connected to the mini-programs of multiple platforms. Using a multi-terminal unified development framework to develop the mini-program code from scratch is both a waste of R&D resources and unrealistic. We need to consider how to use the cross-terminal framework to develop new businesses based on Ctrip’s existing mini-program code, gradually switch the original code, and achieve smooth access to the multi-terminal unified development solution.

2.3 Solution

To solve the above problems, we developed the Ctrip Taro cross-end solution. Developers only need to use the Taro framework to write a set of codes to get a mini program project that runs well on multiple platforms. In addition, the solution also provides warehouse management, auxiliary scaffolding, compilation function extension and process optimization.

3. Taro cross-end solution design

3.1 Technology Selection

In order to achieve multi-terminal operation of one set of code while retaining the original code, we conducted research on the cross-terminal development frameworks on the market and finally decided to use Taro 3 as the cross-terminal framework for Ctrip Mini Programs. This is mainly due to the following four advantages of Taro 3:

• High frame stability
• Supports many platforms
• Supports development using React syntax specifications
• Support Taro and native hybrid development

3.2 Overall Architecture Design

With the development of business, the trend of multi-platformization and the continuous evolution of cross-end technology, Ctrip Mini Program has gradually formed a set of Taro cross-end solutions that can be reused on multiple platforms.

Figure 1 Project Engineering Architecture

The project engineering architecture diagram of Ctrip Mini Program is shown in Figure 1. The upper part is the cross-end reuse layer. The project code of this layer is developed based on the Taro framework. Multiple Taro modules can be flexibly combined into a complete Taro project. From the lower part of the figure, it can be seen that the Taro project is one of the modules of the complete Mini Program project. The operation of the Taro project depends on the Mini Program native shell project. The entire Taro project organizes the code based on the plug-in design concept, and consists of multiple independent Taro modules and a Taro basic shell project.

3.3 Plug-in design of Taro module

First of all, the Ctrip Mini Program is a project developed by multiple teams. When developing across teams, problems such as code conflicts and file overwriting often occur. Therefore, we need to think about how to fundamentally solve these problems through a reasonable project architecture to ensure the efficiency of multi-team parallel development. Considering the concept of modularization, the project code can be broken down into multiple sub-modules according to the business line type, and file placement and reference rules can be agreed upon to ensure that the source code files of each sub-module can be completely isolated.

However, using the modular development solution, the resulting Taro project is almost not scalable, and the Taro module cannot be reused quickly and conveniently. How can we improve the flexibility of the Taro module so that any combination of one or more Taro modules can get a complete Taro project, and can run normally when merged into the mini program native shell project? To solve the above problems, we further applied the plug-in design concept to the Taro cross-end solution, providing a customized Taro basic shell project and a set of development specifications.

Developers need to use the Taro basic shell project as a development template and follow the specifications for business development. All Taro modules are compiled and integrated according to unified standards when they are developed or released locally, so as to achieve the goal of flexible combination without destroying the original project structure. Below we will explain the Taro cross-end solution in detail from the aspects of project composition and development specifications, warehouse management, development architecture, and operation plan.

3.4 Project structure and development specifications

The Taro basic shell project is an extension of the official Taro template project, with customized compilation configuration, plugins, and basic component classes added internally. As shown in Figure 2, the Taro basic shell project only contains files related to public basic functions, which can be abstracted into three categories: compilation configuration files, plugins for extending the compilation process, and page base classes.

Figure 2 Schematic diagram of Taro foundation shell engineering structure

When developing a Taro module, developers need to focus on three areas (extension configuration, project files, and page files, see Figure 2), and follow the following specifications for development:

1) The size of the main package directly affects the performance of the mini program startup. For this reason, we propose the principle of "not putting it in the main package unless necessary": except for the files, tabBar pages and common basic files required for the mini program startup, all other files should be split into sub-packages. The Taro module must also follow this principle. Developers should place all business codes in their own sub-package directories, and only add sub-package page configurations to the project file app.config.js.

2) In order to avoid file overwriting or page path conflicts between business lines when merging projects, it is uniformly agreed that the prefix of the sub-package page path is "pages/business line English abbreviation". Combined with the principle of "do not include it in the main package unless necessary", it can effectively isolate the source code files of each business line.

3) To ensure that the business-related content (including dependent packages) of the Taro module is completely placed in the sub-package path and does not occupy the size of the main package, we provide a commonModule solution: before referencing a third-party dependent package, the developer needs to perform a local pre-compilation operation, package the content to be referenced into one or more commonModule files placed in the sub-package, and then reference the required module from the pre-compiled product (commonModule). In addition, the source code of the dependent package can also be obtained through the commonOrigin solution, at which time the required dependent package will be copied as is to the folder directory specified by the developer.

3.5 Warehouse Management

First, the Taro project adopts a separate warehouse development model, storing the Taro module of each business line in a separate git repository. Storing Taro modules in different repositories can keep the code submission operations of each business repository independent.

Secondly, we use the gitsubmodule tool to include the repositories where each Taro module is located and the Taro basic shell project repository as subdirectories into the release repository of the entire Taro project, and establish a parent-child repository association between the release repository and the multi-business repository. After establishing the association between repositories, the Taro project can use the Get Submodule function of git submodule to quickly clone the Taro module source code it needs, and can pull the latest code of each business repository at any time.

Again, since gitsubmodule allows a repository to be a subdirectory of multiple repositories, this means that you can select different Taro modules and combine their repositories into a new release repository, which can be used in conjunction with the configuration of the Taro modules required by each mini-program in the Ctrip Mini-Program Management Platform to achieve the effect of dynamically introducing Taro modules based on the configuration.

Subsequently, by combining multiple Taro modules, various Taro projects covering multiple business lines can be quickly obtained, thereby improving the reuse of Taro modules in different scenarios.

Figure 3 Warehouse management and module reuse

Then, use the Taro project as a bundle of the complete mini-program, merge the compiled product of the Taro project with the mini-program native shell project, and you can get the complete mini-program code of Taro hybrid development.

As shown in Figure 3, by combining Taro modules, you can get Taro projects containing different functions. Then, by combining the Taro project with different types of mini-program native shell projects, you can easily get multiple Taro hybrid mini-program projects.

3.6 Development and Operation Architecture

Developers only need to install the miniTools scaffolding and execute the initialization command line to quickly obtain the Taro module development template and the mini-program native shell project to complete the project initialization. When developing the Taro module, developers need to follow the development specifications, add files to the sub-package directory, and write business codes. During the writing process, you only need to execute the compilation command to compile the locally developed source code and integrate it into the mini-program native shell project to obtain the complete mini-program code containing the Taro module content.

Figure 4 Local development process

Combined with the above local development process, the specific functions and optimization work provided by the Taro cross-end solution are as follows:

1) The Taro module directly references the module in the Mini Program native shell project. The @/miniapp identifier is provided to refer to the Mini Program complete project root directory. At the same time, the identifier in the code will be identified during the compilation process, and the reference path will be dynamically calculated and modified. When developing the Taro module, you only need to use the relative path of the @/miniapp spliced ​​file to directly reference the files in the Mini Program complete project root directory.

2) Extend the page configuration items to provide the function of setting the nesting level of custom components. Developers can add the nesting level configuration of custom components in the page configuration file. When compiling, the content of the page configuration file will be retrieved to summarize and set the nesting level of custom components used in the Taro project.

3) Dynamically generate splitChunks based on the subpackage path . In order to prevent public files from being included in the main package (occupying the size of the main package), the subpackage path configured by the Taro module will be read during compilation to dynamically generate splitChunks. This solution can extract the public files used in the subpackage separately into the subpackage, and then add references to the subpackage public files to all pages in the subpackage.

4) Provides an extended configuration file that allows you to add aliases and externals configurations, making it easier for developers to customize directory aliases and dependencies that do not need to be packaged.

5) Provides module analysis function, so developers can more easily view which files are included in each chunk

6) Use hybrid mode for packaging , then automatically move the compiled product to the mini-program native shell project, and add the sub-package configuration to the mini-program project configuration. This step is to merge the Taro project compilation product with Ctrip's original mini-program code into a complete Taro hybrid mini-program project. Under the influence of development specifications, the sub-package path of the Taro module is isolated according to each business line, and the files of each Taro module are strictly placed in its own sub-package path. Therefore, you only need to place the public basic files in the project root directory and migrate the sub-package content to their respective sub-package directories to successfully complete the code merger.

3.7 Project Release

We use webhooks to implement the pipelined iterative development of the Taro project. When the Taro module is submitted for modification, the pipeline of the Taro project release warehouse will be triggered. The main workflow of the Taro project release warehouse pipeline is as follows:

First, the Taro project will pull the latest code from all sub-repositories. Then, it will obtain the list of Taro modules and corresponding release version numbers used by the current Taro project from the mini-program management platform, and pull the release code of each Taro module into docker as needed. At this point, all the source code that the Taro project needs to release has been obtained.

Figure 5 Automated CI/CD

Next, we will merge the Taro project: switch the code of each Taro module to the specified version, obtain the subpackage path configured in each Taro module, and merge the relevant configuration files and business codes under the subpackage directory into the Taro shell project.

After the Taro project is merged, it will be compiled into the code of the specified applet type. It is worth mentioning that the Taro basic shell project is both a Taro project shell and a development template. It provides a unified Taro project structure and compilation method, which is also the reason why Taro modules can be flexibly combined.

Finally, the compiled product of the Taro project is merged with the native code of the corresponding type of mini program to obtain a complete Taro mini program project. Uploading the project code to the mini program backend marks the successful completion of the entire project release process.

IV. Conclusion

Currently, Taro's cross-end solution supports running one set of code on five types of mini-programs (WeChat, Alipay, ByteDance, Baidu, and Kuaishou). Taro mini-program projects developed using this solution are highly flexible and reusable, and Taro modules can be selected as needed to form a complete Taro project.

In addition, we also provide supporting scaffolding tools, warehouse management, version management, and pipeline automation solutions, which greatly improve the efficiency of mini-program development, testing, and release. In the future, we will continue to improve the mini-program ecosystem and continuously incubate more solutions to solve business pain points.