The author | Zhu Tianjian
Edited | Jayanin
This article was compiled by InfoQ from Zhu Tianjian, senior front-end engineer of JD Retail Platform Business Center, to share "Taro's Choices and Challenges under the Multi-terminal Wave" at the GMTC Global Front-end Technology Conference (Shenzhen Station) 2021.
Multi-terminal research and development for the front-end development of today's era is a topic that cannot be bypassed, in order to solve these problems, the open source framework launched by the open source projects of major companies is not in the minority, and Taro has been open source for more than three years since 2018, and has gained more than 3W Starred on GitHub, helping many teams and developers after open source, we also explore the way forward through communication and feedback with more than 10,000 active users in the community, and build a community with many developers Taro grew up together.
What a multi-terminal solution we need
Mini Program ecological co-prosperity
What kind of multi-terminal solution do we need? From Taro's point of view, our basic premise is that we hope that multi-terminal will not become an obstacle for developers, especially when the Mini Program ecosystem as a whole is thriving, we expect that the entire ecosystem can continue to grow and achieve mutual achievements with developers.
In recent years, every once in a while, many new Mini Program platforms have emerged, bringing more traffic channels and creating many problems for developers.
Mini Program Platform
Product students can easily shout "I want it all!" ", so can we as developers? Whether it is the Web, React Native, or various small program platforms, it is bound to involve a lot of energy in the development process. In particular, the platform side often does not have enough time and energy to take care of the development experience of all developers, and for many developers of cross-end frameworks, adapting to a new platform is bound to be an easy task.
Cross-platform development is an important force for the continuous expansion of the Mini Program ecosystem, and it also makes the Mini Program one of the cores of the rapid expansion of the Internet ecology. This is why we expect the Mini Program ecology to be built together, and the addition of each new member brings not only traffic, but also fresh vitality, which will promote the prosperity of the entire ecology.
Development performance and experience
However, it is necessary to mention here that but!!! What is the cost?
In the face of the synchronous development of multiple platforms, we often encounter many problems, such as: in order to synchronize multi-terminal capabilities, it is often difficult for us to respond quickly to business needs; if we use native development, each additional platform, the research and development costs are exponentially increasing; and the completion of development does not mean that the task is over, and the difficulty of maintaining these multi-terminal homogeneous and differentiated code can be imagined.
Therefore, what developers need is nothing more than a multi-terminal and integrated development experience; they hope that the framework can have excellent performance while being comfortable in development and maintenance. Plugins are also very important capabilities, which can be completely selected for many projects that do not require capabilities; and for more community developer groups, if there are special needs, they can be implemented through customized plugins without waiting for an official response.
For open, open source communities, developers
Essentially, we need the ability to open the framework for development, for teams in the open source community, and for many of those developers.
Support for more frameworks
We want to give developers the freedom to choose their favorite framework, whether you like React, Vue or more solutions, you can use such a multi-terminal solution to implement their own ideas without restriction, which is the spirit of open source, and it is also the purpose of our open source projects.
Of course, this is also the open cross-end cross-framework solution that Taro provides to all developers in the community.
Highly scalable, open architecture
Nothing happens overnight, and many of the problems we face are the same for the Taro team. Although we have just mentioned a lot, these contents are also slowly realized by our set of footprints. In its earliest days, Taro was not so open, it only supported react Like way to write small programs, and it was also a recompiled framework.
Taro architecture
As shown in this architecture diagram, we parse the developer's React Like code through AST, convert it into the corresponding Mini Program code, and adapt all The Mini Programs can be completed through the adaptation layer. Although we can talk about all our work in one sentence, many of the difficulties are unimaginable, and we find that the cost of maintaining the framework is gradually exceeding the limits that we can accept, so we choose to take another big step forward.
Plug-in schema
I have to say that the plug-in architecture has helped us a lot, we have split everything that can be split, almost all the capabilities are provided through the plug-in way, and finally form the framework of Taro 3.x.
After Taro 3.x adjusts the overall framework, the cost of adapting to the new framework is greatly reduced, and by aligning the components and life cycle, we can introduce a new framework into the Taro ecosystem.
Taro 3.x architecture
Of course, the implementations of the Web, React Native, and Mini Programs in this architecture are slightly different. In the Mini Program, we need to inject the DOM, BOM and provide the renderer of the corresponding framework, and finally package it for developers to use through Webpack; the Web side provides standardized components through WebComponent, while simulating all APIs for developers in combination with the standard routing system; the same logic is also in React Native, packaging standardized components and APIs for developers to use through Metro.
End-platform plug-ins
The plugin architecture helped us introduce a new concept, the end-platform plugin, which helps us to split the capabilities of each side, and the plugin can translate into the corresponding code of the corresponding end by providing compile-time templates, components, compilation configurations, plus the components, APIs, and renderers required at runtime, respectively, into the Taro CLI and the corresponding lifecycle in the runtime.
Taking the WeChat Mini Program plugin @tarojs/plugin-platform-weapp as an example, we usually organize the project file as follows:
Implement the compilation of the end platform by inheriting the base class TaroPlatformBase, and then call the compilation interface of the custom platform class above in the plugin entry function:
runtime.ts is the entry file for our runtime, which Webpack will inject into the app .js for reference at compile time.
Use the mergeReconciler function to merge custom hostConfigs into the global Reconciler;
Use the mergeInternalComponents function to merge custom component information components.ts into the global internalComponents component information object.
Refer to @tarojs/plugin-platform-weapp plugins We can quickly register a small program plugin on the other side and scale out the required components, APIs, renderers, and runtimes for customization. Of course, it is also possible to expand a platform plug-in vertically on this basis, so that you can quickly complete the development of similar Mini Program platform plug-ins.
Of course, the design of the entire plug-in architecture is not only for building terminal platform plug-ins, all kinds of plug-ins can improve the Taro ecosystem well, provide a better development experience, many development teams or individuals in the community have provided very interesting plug-ins for various research and development scenarios, welcome to experience.
Cross-frame adaptation
Adapting the framework is not a very difficult thing for Taro today, because Taro provides its own simulated browser environment.
Browser Object Model
Simulates a browser environment
As the foundation of the browser environment, BOM and DOM-related APIs are essential, which is also fundamental for various front-end frameworks to run in applets.
Taro RuntimeTaro
Build your own runtime environment by simulating these APIs, presenting all events and node methods in a mini-program environment in the form of alignment web standards.
Taking the basic click event as an example, when the tpl_text node in the mini program triggers an event, the framework will find the corresponding event through the getElementById method provided by the Taro DOM Tree to find the onClick method on the text and trigger it.
The bubbling mechanism is also an important part of the event, so the onClick method on the parent node tpl_view is also triggered, and the propagation of the event needs to be stopped by calling the stopPropagation method.
Framework compatible
After completing the construction of the browser environment, it is relatively easy to be compatible with various frameworks, and the standard events provided by Taro can be associated with the life cycle of the framework and the mini program, which can allow developers to have a smoother experience when using it.
The first thing to do is to mount the portal, which will mount the built DOM tree when the mini program triggers the onLaunch event, of course, each framework has its own way of writing, such as render Vue in React is $monut method.
Next we need to mount the page, inject information such as ref into the page when the page triggers onLoad, and render the page. Each page will have its own pageId, which also allows us to map all the life cycles to each page one by one, touching them at the right time.
When the lifecycle is aligned, the page just needs to be rendered, of course, each frame here will be a little different. Take React as an example, ReactDOM as a renderer, very feature-rich, but the package is large and not all of them need to be used in the mini program, choosing to use react-reconciler custom renderer refinement is an easy decision to make, plus hostConfig injection of the corresponding dependencies, taro-react is completed.
Adapt to react custom renderers
At runtime, you can create a Taro DOM Tree by creatingReactPage and render it using setData and template interaction data.
Images adapt to react rendering flows
The same is true with Vue in Taro, where the entire process can be completed by creating a DOM Tree by calling createVuePage.
Adapt to the Vue rendering pipeline
Of course, if you use Taro to support the new framework, you may encounter some problems, such as DOM/BOM related API missing or functional errors, etc., you can feedback through issue, we will dynamically expand.
Cross-end adaptation
For Taro, there are many ends, small programs, React Native, web, fast applications, many of which are helped by the community to complete the adaptation. Here we take the Mini Program as an example, Taro DOM Tree in the rendering process according to different Mini Program platforms will actually be different, but are based on the template component provided by the rendering method.
Rendering schemes 3-1
Through the one-to-one correspondence of templates, we can complete the rendering of all components, but the template functions of different platforms are differentiated, some support recursion, and some do not support, which is divided into two different mini program categories. For example, Ali, Toutiao, Baidu's mini programs all support recursion, and we can let the template call itself to avoid duplication.
Rendering schemes 3-2
WeChat, JD.com, QQ Mini Programs do not support, we will create new templates. Template patterns that do not support recursion may of course have some problems, such as template files are too large, but we can optimize the number of recursive levels reasonably by setting the baseLevel configuration; also because custom component styles will have an impact, avoiding nesting is also an optimized solution.
Rendering schemes 3-3
Applets
I don't know if you tried to use Taro to compile Kuaishou, Mango, Feishu, or even Alipay IOT Mini Programs? Some of these new platforms are provided by the official mini program platform, and there are many teams or individual developers of other companies that develop and provide according to their own business needs, of course, we also look forward to seeing more Taro platform plugins written by everyone in the community.
Ecological fusion of Mini Programs and H5
Speaking of the ecological integration of Mini Programs and H5, I don't know what everyone will think of? May also be confused about what is ecological integration? Why does Taro do eco-integration? And how to achieve the integration of ecology?
What is eco-integration?
Taro has supported so many Mini Program platforms, but also supports the H5 side, so is it that everyone uses the Taro framework, and the ecology of the Mini Program and H5 can be integrated? Obviously not.
There are a large number of exclusive Mini Program plugins in different Mini Program ecosystems, if developers want to use Taro and directly use these exclusive native Mini Program capabilities? Obviously, there will be no problems that will hinder this.
So can the native Mini Program be converted to an H5 application via Taro? With Taro's convert directive you can complete the process of native to Taro project, and Taro can help you transition to any platform to use.
So is that enough? If I have a native project, can I use components written by Taro? Some students may say that Taro can compile mini program plug-ins, and you can export plug-ins to use Taro in native applications. But in fact, Taro also provides blended instructions that can compile Taro projects to a specified platform for native Mini Programs or other application integrations.
Is there anything else? Can Taro use web components directly in the Mini Program?
Use HTML tags
If you think about it, it's totally okay! So we've added a plugin @tarojs/plugin-html to do just that.
Implementing this plugin in general, our task is mainly divided into three directions, respectively, the label name, attributes, component mapping can be, of course, in fact, there will still be a lot of problems, but this is valuable, especially it has a high voice within the community. The most important reason is that we can use the various tools on the web side directly in the mini program through this plugin, especially some component libraries, which we can use directly in Taro without special consideration of cross-end issues.
For example, Ant Design, Vant and WeUI have provided demos for the community to use directly, which will further break through the ecological barriers of the Web and mini programs, and many old projects can be run directly on the mini program side, which will also be a great convenience.
The Picture Mini Program uses the web-side ecosystem
Of course, this is not unlimited, for example, the DOM API will have some differences:
Synchronous calls are not supported in some applet APIs
Some of the applet component APIs need to be called through Context
There are also some special uses, including some label nodes, which are used differently:
Inserting nodes outside the DOM Tree is not supported (React's Portal, Vue3's Teleport are not supported)
ReactDOM feature refinement (Taro uses react-reconciler to customize the debugger)
Applets do not support partial styles or CSS selectors (the default width and height is not the original image width and height)
Applets do not support svg
For more details of the restrictions, please refer to the relevant documentation on the official website.
The opportunities and challenges brought by Hongmeng
Can Taro also support Hongmeng? This is the sentence I hear the most in many community communication groups, but in fact, Taro's support for Hongmeng is very feasible, after all, OpenHarmony's JS UI syntax and mini programs are very similar. So in fact, as early as the first exposure of Hongmeng, the teams of the two sides had a lot of in-depth exchanges and discussed the relevant feasibility, of course, until recently we had enough manpower to complete the adaptation of the Hongmeng platform.
Taro has many collaborations with Huawei and the Open Atom Foundation, but it can be summed up that Taro is about to join OpenHarmony and establish CrossPlatformUI Sig to provide support for Hongmeng's cross-end capabilities.
For Taro, we can also adapt to Hongmeng in the form of plug-ins, and expand it as a platform to complete the access of Hongmeng.
Of course, in order to erase the differences between Hongmeng and other platforms, we need to deal with a lot of problems, such as supporting React & Vue syntax, supporting standard components and APIs, etc., supporting syntax can be implemented by writing the runtime of the framework, and components and APIs need to be implemented through the capabilities provided by OH.
In the end, we can see that the code we write can be packaged into an application through webpack, and the data and events are interacted with the UI view through the runtime provided by Taro at the front-end framework layer, plus the basic capabilities provided by OH can adapt rendering for the Hongmeng side.
Taro adapts to the rendering flow of OH
Taro for Harmony related capabilities will be released as a feature of the v3.5 version, the canary version has been released, welcome to try, we will continue to improve the relevant capabilities with many developers in the community, and provide support.
Summary and outlook
Finally, there's a lot more to Taro to do, so let's briefly summarize and look at it here.
Taro for Harmony
First of all, on Taro for Harmony, just mentioned in fact, we will soon release the official version, is currently inviting community students for internal testing, the official version release time, we expect that in March 2022, everyone is interested in can pay attention to, of course, you can also join Taro's Hongmeng exchange group through the small assistant to get more information.
Cross-platform testing
Cross-platform testing has always been the focus of community developers, we actually have two sets of internal solutions in the continuous iteration, but for many reasons have not been open sourced for everyone to use.
Sandbox testing
As a set of self-developed solutions, the test sandbox can fully adapt to the logic test of the full platform Mini Program and the Web side, and assist developers to complete the mini program-related ability test by simulating the DOM structure, life cycle and API of the Mini Program; on the Web side, it obtains the application and Taro instances by parsing the AST that generates the code, and combines Jsdom to simulate the actual browser environment to achieve a consistent test experience with the Mini Program.
Automated testing
Another scheme, TIga, is relatively more realistic, through the puppeteer and mini program officially provided interface in the browser environment or mini program official platform to complete UI testing, currently support the Web and WeChat Mini program, in the use of internal projects are also widely praised. Both solutions have their own focus, and I hope to one day open source and meet with developers in the community.
Cloud IDE
Cloud IDE, that is, the Tide project, has also poured the efforts of many members of our team, through the built-in Taro research and development process, it has solved many itch points in the development process of mini programs, such as templates, plug-in management, multi-terminal configuration differences, version management and other engineering problems.
Team collaboration between products, design, R&D and testing in large-scale Mini Program projects; at the same time, through the built-in Mini Program simulator, the developer tool simulator is avoided repeatedly switching in the debugging window; the Mini Program testing on-line process, online environment monitoring... These current internal uses have been well received and have helped us solve many of the problems within the team.
At the end of the article, two questions of concern are answered:
1. Direction of Taro3 performance optimization
In fact, there were also students at the meeting who mentioned that Taro supported preact in version 3.4, and indeed whether it was Taro-react or support preact was Taro's attempt in the package volume scheme, and we also intended to improve the performance of Taro3 in the Mini Program through wasm. Although Taro3 does not currently have an official benchmark, it is still in the works, so stay tuned.
2. Subsequent versions of Taro3 are planned with Taro4
For Taro4 there is no comment at present, but in the subsequent version of Taro3 features, you can pay attention to our open Task List, and vote on the current Feature Request, for many new features in development can be seen here, of course, if you have any ideas can also be submitted here, if you want to participate in the development of some features, you are also welcome to submit PR.
About the Author
Zhu Tianjian
Senior front-end engineer of JD Retail Platform Business Center
In 2019, he attended the 2nd Software Green Alliance "Building Ecology and Building the Future" Developer Conference as a lecturer, and was invited to participate in the 4th TLC Tencent Live Conference in 2020. As the core development member of the Taro framework, he is mainly responsible for the research and development of multi-terminal component libraries and APIs, and is also responsible for the open source community management robot group control system; the core development member of the Tide project is mainly responsible for the research and development of tide-site and cloud ide, third-party call protocols and related interfaces, and Taro-related ecological plug-ins.
Event recommendations
On June 10-11, 2022, GMTC Beijing will meet you again! With the theme of "Business First, Efficiency is King", the conference covers 15 cutting-edge technology topics such as front-end performance optimization, IoT dynamic application development, TypeScript, mobile performance and efficiency optimization, etc. Click at the bottom [Read more] to go directly to the official website of the conference, and more wonderful content continues to be polished online. 30% off conference tickets, $1440 off! Interested students contact the ticket manager: 17310043226.
Click on one to see fewer bugs