About the Author

Frank, Ctrip's front-end R&D, focuses on front-end performance optimization, one code for multiple terminals, engineering construction and other fields.

1. Business background

With the popularity of mobile Internet and smart devices, front-end developers need to use multi-terminal isomorphic technology to adapt to different terminals (mini programs, apps and web). There are obvious differences between these terminals, including browser engines, operating systems, interaction methods, and coding languages.

These differences bring many challenges to front-end developers. On the one hand, different terminals use different browser engines and operating systems, resulting in different page rendering and interactive behaviors. On the other hand, the coding languages and development tools used by different terminals are also different, requiring developers to have different technical backgrounds and knowledge in order to write multiple codes to adapt to different terminals. Doing so not only increases the development workload of R&D personnel and the difficulty of code maintenance, but may also cause users to encounter inconsistent user experiences on different devices, affecting product quality and user satisfaction.

In order to solve these problems, multi-terminal isomorphic technology emerged as the times require. Through multi-terminal isomorphic technology, the tourism front-end and public teams cooperate in multi-terminal exploration and practice, and flexibly adapt and customize according to the characteristics of different terminals. This can reduce development costs and maintenance difficulty, and improve development efficiency and code reusability. At the same time, multi-terminal isomorphic technology can also provide a consistent user experience. No matter which device users use to access the application, they can get similar interfaces and functions.

Industry Status

tripartite isomorphism

2. Selection of multi-terminal isomorphic technology

When selecting multi-terminal isomorphic technologies, we need to comprehensively consider cross-terminal capabilities, cost, performance, code language versatility, and support of existing technologies. This will help us choose the most suitable technical solution. The following is an analysis of the current mainstream cross-end technologies on the front end:

	Hybrid	React Native	Flutter	Weex	Taro
Cross-end capabilities	★★★★	★★	★★★	★★★	★★★★
cost	★★★★	★★	★★	★★	★★★
performance	★	★★★	★★★★	★★★	★★★
Code language versatility	★★★★	★★★★	★★	★★★	★★★★
Ctrip support	★★★	★★★★	★★★★	★	★★★★

Hybrid : Using JavaScript language, it supports the rapid construction of multi-terminal applications. Because it relies on the Webview container to run, its user experience and performance are subject to certain limitations. This limitation can cause problems such as slower application response times and longer page loading times. It is suitable for scenarios where the three-end business requirements are relatively high, R&D costs are relatively low, and performance requirements are not high, such as marketing advertising pages.

React Native : React components developed using JavaScript language, support building apps and web, but do not support native applets. The App has performance and user experience close to native applications. It is suitable for scenarios where the performance requirements of small programs are not high.

Flutter : uses the Dart language and its own rendering engine, and the support range is the same as ReactNative. It performs better than ReactNative in terms of rendering speed and user experience. Due to the restrictions of the iOS platform rules, it is currently not friendly to hot update support. It is suitable for scenarios that have high performance requirements for apps and low performance requirements for mini programs.

Weex : A component of Vue developed using JavaScript language. The support range and performance are the same as ReactNative, but the community activity is not as good as ReactNative.

Taro : an open cross-end and cross-framework solution that provides a unified set of development syntax and component specifications, allowing developers to use a set of codes to develop native applications that adapt to different platforms. It is suitable for scenarios with high requirements on three terminals and high performance. Since the design was originally designed for small programs, the specifications are not friendly to ReactNative R&D.

Considering that our business has high requirements for multi-terminal and performance, combined with the existing team's technical reserve capabilities, we chose Taro's multi-terminal isomorphic technology solution. In this article, we will focus on the problems encountered and the corresponding solutions after the tourism department ticket event front-end team and the public wireless technology team cooperated to integrate the Taro technology stack with existing technologies.

3. How to integrate Taro with existing technologies

The multi-terminal isomorphic technology provided by Taro can be used directly without considering the integration with the existing technology stack. If you already have a set of technical solutions, you need to consider how to integrate Taro with existing App or Web technologies.

Taro cross-end solution is a solution based on static compilation. The final product is to compile the source code into target code and package it into an executable file. This file can neither be directly integrated into the framework of the business side (Ctrip) RN or Web, nor can it directly call the business components provided by Ctrip, such as cities, calendars, payments, etc. Therefore, developers need to adapt Taro before they can solve the problem of integrating with existing frameworks.

As shown above, the core principle of Taro is to replace the original small program components and APIs with components and APIs adapted to different platforms by injecting custom configurations during compilation and build, thereby achieving multi-terminal capabilities. In this way, the same code can be used in business development to adapt to different terminals, eliminating differences in multi-terminal development.

3.1 Integrated App (integrated with Ctrip React Native technology)

1) In Taro’s configuration file, inject custom plugins

2) Perform alias replacement through Metro packaging configuration (replace the original taro reference with the new RN path)

3) Smooth out Taro’s components and APIs

Text component

Page jump API

Follow the above steps and combine it with ReactNative's scaffolding to get it running.

3.2 Integrating the Web (integrating with Ctrip NFES technology)

Taro isomorphic technology is available in non-SSR and SSR modes on the web side. The SSR mode is based on the NextJS framework and is supported by providing the compilation plug-in tarojs-plugin-platform-nextjs. However, since this compilation plug-in does not support Web frameworks or other Web frameworks based on NextJS technology extensions, it is necessary to use the open compilation capabilities in Taro scaffolding to replace APIs and component libraries with ones that support server-side isomorphism through the babel plug-in during construction. version, and at the same time generate the directory and project configuration that adapt to the current framework, so that Taro has the ability to convert to the corresponding Web framework. Please refer to the following steps for details:

1) Same as RN, inject custom H5 plugins

2) Package configuration through Webpack and perform alias replacement

3) Smooth out Taro’s components and APIs

Text component

Page jump APIs

4) Adjust routing, middleware and other project configurations according to your own framework. The following is an example diagram of Ctrip NFES.

Follow the above steps and combine it with your own Web scaffolding to get it running.

4. Technical Practice

After solving the problem of integrating the Taro multi-terminal framework with existing technologies, it is necessary to further improve the richness of components and APIs, improve the performance of applications, and solve the problem of CSS adaptation to reduce development costs and improve user experience. Target.

4.1 Component library and API

1) Richness of components and APIs

The core solution of Taro's multi-terminal isomorphism technology is to achieve cross-terminal isomorphism by smoothing differences in component libraries and APIs, thereby making performance and user experience consistent with independently developed single-terminal applications. However, the disadvantage of this approach is that component libraries and APIs on each end need to be developed to align with the Taro applet, which requires a large initial cost.

Taro multi-terminal design has taken into account reducing the initial investment cost of R&D personnel, so it provides more than 60 component libraries and APIs aligned with Taro applet. It has been proven in practice that it has met most common business needs.

In addition to the provided components and APIs, it is still necessary to develop business-oriented extension components and APIs, such as elastic layers, folding, calendar and city selection components, as well as payment, login, etc. (as shown in the figure above). Most components only require secondary packaging on officially provided components, and the research and development costs are not large.

2) Multi-terminal components and API differences

There may be some differences in multi-terminal components and APIs on different platforms, which cannot be completely smoothed out. Each platform has its own characteristics and limitations, so when developing multi-terminal applications, these differences need to be adapted and handled.

For example, there are differences between different platforms in animation implementation. In ReactNative, you can only use the Animation component to achieve animation effects. On the mini program and the Web, CSS styles are used to achieve animation effects. In order to maintain multi-end consistency as much as possible, the animation implementation is encapsulated into a unified component so that it can be used on different platforms. used on. The encapsulated animation component is called the Animation component on the RN side, and the animation is implemented on the mini program and Web side by adding CSS styles through Js within the component. This method solves the differences in animation implementation, allowing developers to use a unified interface to call animation effects without paying too much attention to the specific implementation details of different platforms.

The above flattening problems can be summarized into the following three categories:

Situation description	solution	For example
Both A and B have this function, but the difference is not big.	Smooth out the differences	input, routing jump, etc.
Both A and B terminals have this function, but they are very different.	Smooth out the differences	Animation components are encapsulated into a unified API
Side A has this function but side B does not	Degrade Smooth Difference or Difference Smooth	Difference smoothing: Each end implements each end. For example, RN uses Flatlist and other ends use scrollview. Downgrade and smooth: some are displayed, and some are not displayed. For example, the head navigation bar does not exist in the mini program.

4.2 CSS adaptation

The cross-end support of CSS is weak and is limited by the platform limitations of ReactNative, so the support is not friendly.

ReactNative does not support nesting of CSS styles. You can only split the style into multiple independent objects and merge them into one object through the StyleSheet.flatten method to set independent styles on a hierarchical node. Currently, the multi-terminal method can only be adapted through differential smoothing, sacrificing the flexibility of CSS on other terminals.

ReactNative does not support pseudo-element selectors in CSS. Such as ::before and ::after because it has no DOM elements and does not support these selectors. You can adapt the selector writing method by adding HTML nodes.

The above writing method limits the efficiency of multi-terminal development, but does not affect the functional realization of the product. Most of the other style issues can be smoothed out using Babel plug-ins (such as rn-style-transformer).

Platform default attribute differences

Attributes	ios-rn	android-rn	web	Applets
fontSize	14	16	16	16
color	#000	#777	#000	#000
margin	0	0	8	0
padding	0	0	1	0

Platform properties support differences

Attributes	ios-rn	android-rn	web	Applets
background	not support	not support	support	support
position：fixed	not support	not support	support	support
textIndent:number	not support	not support	support	support
dashed	not support	not support	support	support

4.3 Performance

Because Taro uses static compilation to generate platform code, its performance is better than dynamic compilation. The performance on the App side is equivalent to that of native RN, but on the Web side, Dom nodes will be replaced by Web Components, and the rendering capabilities of Web Components are lower than native components. Therefore, if there are a large number of Web Components during the conversion process, page rendering will slow down. Under the test conditions where the computer model is MacBook Pro (14-inch, 2021), the browser model is chrome, and the browser version is 113.0.5672.63 (official version) (arm64), the taro-view-core (View) component is For example, if the rendering is repeated 2000 times, the total time consumption is approximately 123ms. If you switch to div and re-render it 2000 times, it will take about 17ms, which is about 7 times different. The experimental screenshot is as follows:

Web Component takes time:

Native div takes time:

From the above experiments, it can be concluded that instead of directly using components such as View and Text provided by Taro, wrap a layer of components with Taro functions on top of the native Web components.

5. Applicable scenarios and costs

5.1 View layer isomorphism

According to the needs of interaction and product design, it is recommended that a set of Views be used for Apps, H5, and mini programs whose interaction methods are more than 70% similar, and the differences can be realized using the file extension provided by Taro Project.

Since the interaction methods on the PC side are quite different, it is usually necessary to write two sets of View components, which is more appropriate.

5.2 Applicable scenarios for multi-terminal isomorphism

Multi-terminal isomorphism is suitable for applications that need to provide the same functions on multiple platforms to improve development efficiency and user experience.

It is not suitable for applications that have high performance requirements and are highly dependent on the exclusive features of the platform, such as games based on canvas. For scenarios that are not applicable and multiple platforms need to be supported, they can only achieve their own effects.

5.3 Cost of multi-terminal isomorphism

Although multi-terminal isomorphic technology can reduce development costs, there are still differences in styles and APIs between different platforms, which require R&D personnel to adapt and supplement. For actual comparison of R&D costs at each end, please refer to the following table:

	R&D costs	After multi-terminal isomorphism	Remark
App	1	0.2
H5	1	0.2
Applets	1	1.2	First developed platform
PC	1	0.4
total	4	2.2

As development experience accumulates and components are enriched, R&D and testing costs will be further reduced.

Learning cost: Multi-terminal isomorphic development requires developers to have cross-terminal development capabilities and experience. They need to understand the characteristics and differences of each platform. They also need to pay attention to the performance, maintainability and scalability of the code. We can improve their abilities and skills through a variety of training and sharing.

Testing cost: In a multi-terminal isomorphic development model, if one terminal is accidentally corrected, it will affect all terminals, so the testing cost will increase. The wider the testing scope, the longer the testing time and therefore the corresponding increase in testing costs. In addition, due to the differences between different platforms, testers need to have the ability to test across platforms, which will also put higher requirements on testers' R&D capabilities. In order to solve these problems, UT (unit testing) and AT (automated testing) can be popularized, which can reduce testing costs and improve testing efficiency.

Production stability: Because multi-terminal isomorphic technology uses unified code logic and component encapsulation, once a problem occurs, multiple platforms will be affected. Therefore, rigorous testing and quality control are required during the development process to ensure the stability and reliability of the code.

6. Summary and Outlook

This article introduces the use of Taro to achieve multi-terminal isomorphism, reduce R&D costs and improve user experience in cross-multi-platform business scenarios. By using the same development language and code framework, code can be reused on different ends to achieve the purpose of unifying business logic.

It is foreseeable that in the near future, more solutions will emerge, whether based on business needs or technical practice and innovation, making the road to multi-terminal development smoother. At the same time, this solution will become the company’s main multi-terminal framework.

[Recommended reading]

“Ctrip Technology” public account

Share, communicate, grow

Dry information | Ctrip Taro multi-terminal exploration and practice