Front-end early chat conference, a new starting point for front-end growth, jointly held with the Nuggets. Add wechat Codingdreamer into the conference exclusive small program group, to win at the new starting line.
The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :
The text is as follows
This is the 67th session of the 10th front-end Early Talk. JJ from JINGdong Taro team shares a brief and organized version of the lecture (please see the video and PPT for the complete version with the demonstration) :
Good afternoon, everyone. My name is Chen Jiajian from JINGdong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong Dong
Foreword, Taro framework
Taro is an open source multi-terminal unified development framework, which allows us to write a single code to run this program on various aprons, H5 terminals and RN terminals. After two years of open source, Taro has gained a lot of attention in the industry, and now has more than 25,000 stars on Github. At the same time, many teams in the industry are developing using the Taro framework. So over the past year, we’ve been planning a big redesign, Taro Next, which I’m going to share with you today.
First, Taro Next
First, there are two main reasons why we refactor. The first is to address some of the flaws in the current architecture, and the second is to add support for multiple frameworks.
1.1. Taro Architecture
First, take a look at the overall architecture of Taro. It is divided into two parts, the first part is compile time and the second part is run time. During compilation, the React code is first compiled and converted into code that can be run by small programs on each side. Then, a corresponding runtime framework is adapted to each side of the small program to make the code run on each side of the small program. So what’s wrong with this architecture?
1.2 Taro compilation defects
First look at the implementation process of compilation: compilation is to use Babel to carry out lexical, grammatical and semantic analysis of the source code to obtain an abstract syntax tree AST, and then carry out some conversion operations on this abstract syntax tree, and finally obtain the target code. This implementation has three major drawbacks:
- JSX support is not perfect. Taro’s support for JSX is implemented through compile-time adaptation, but JSX is too flexible to support 100% of the JSX syntax.
- Source-map is not supported. Taro does not support source-Map after a series of transformations to the source code, making it difficult for users to debug and use the project.
- Maintenance and iteration are difficult. Taro builds code that is complex and discrete, making it difficult to maintain iterations.
1.3 Taro runtime defects
Next, take a look at runtime defects. Now for each applet platform, we provide a corresponding runtime framework for adaptation. It doesn’t make sense to change multiple run-time frameworks at the same time when we need to fix bugs or add features.
1.4. Want to support more frameworks
On the other hand, we also want to support more frameworks. Taro currently only supports React, but there are many teams within the company that use the Vue technology stack, and they want to enjoy the ability of Taro to compile to multiple ends. Therefore, we wonder if we can support Vue, or even jQuery, Angular, and other frameworks.
Taro Next New features
After explaining the reasons behind the redesign of Taro, we’ll talk about the new features of Taro Next following the redesign.
2.1 Taro Next Architecture
This is the overall architecture diagram of Taro Next. Although the frameworks of each Framework have different component libraries, life cycles and apis, we can still select wechat applet as a benchmark, and then use various frameworks to connect with the component libraries, life cycles and apis of wechat applet. Internally, the missing parts of each platform are completed. For example, in the small program, it does not have DOM and BOM, so we need to implement the corresponding DOM and BOM. Then in the H5 side, there is no component library, routing specification, API and so on of wechat small program specification, so we also need to implement it. Finally, we use Webpack to package the runtime code. You can make the entire code run on different platforms.
First, Taro Next
Overall, Taro Next has three advantages. The first point is that Taro Next is much more powerful. We are now free of language and syntax, can run a variety of real frameworks, and provide features such as rendering HTML and cross-frame components.
2.3 Taro Next Advantages two
Second, Taro Next is faster. We stripped away the AST operations to make builds faster. Second, we also improved the performance of project initialization and update operations. In addition to Taro’s own optimizations, we also provide a series of optimization options for users to call the project based on their actual situation.
2.4 Taro Next advantages three
The third point is more flexible, we now provide a plug-in system, users can according to their own scenes to expand some of their own capabilities. We have also exposed Taro’s internal configuration items and Webpack’s configuration items, so that users can configure more items. Secondly, the dependency on Taro has been reduced. Now Taro users can install corresponding dependencies according to their actual situation, instead of packing all dependencies into the CLI of Taro as before.
Development practice
Learn more about how to use Taro for development after you’ve reviewed the new Taro Next features.
This section will be divided into five sections, starting with some preparation before development, then starting coding, project progression, multi-side development, and performance optimization.
3.1 preparation
Let’s take a look at what kind of preparation we need to do before development.
3.1.1 Environment Preparation
First we need to install Taro’s CLI tool. If you want to create a new project, you can use the init command to create a new project. If users already have a wechat applet project, we also provide convert command, so that users can convert their wechat applet project to the Taro project, after receiving the Taro project, you can run the build command, and then run the Taro project to each end.
3.1.2 Preparation for project configuration
Before we can start coding, we first need to do some configuration for Taro. Taro has a configuration file that can be divided by region into common configuration, applets configuration, and H5 configuration. By category, it can be divided into Taro internal configuration items and Webpack-related configuration items.
3.1.3 Preparations for Babel Configuration
The Babel configuration of the Taro framework is currently included in the Taro configuration we just mentioned, but with Taro Next we have updated babel7. For preset, users can use the Babel configuration file babel.config.js, which includes Taro’s preset, a race in which presets and plugins are commonly used. Such as @babel/preset-env, @babel/ plugin-transform-Runtime, etc. Then, if users use React or typescript, they add the corresponding presets.
3.1.4 Preparations for App and Page configuration
Let’s look at the App and Page configuration. Taro also has an entry configuration file app.config.js, and each page will have its own configuration. However, unlike the application, the current Taro can only write json configuration. Tarol Next uses @babel/ Register to load these configuration files, so users can write these configurations using ES Next syntax, which gives them more flexibility.
3.2. Start coding
Now that we’ve done the configuration we need to do before the project starts, we’ll look at how we can start coding.
3.2.1. Entry Components
As with applets, we’ll start by writing an entry component, app.js. The React Component is a regular Component with a Vue instance. First we need to introduce the corresponding framework, and then if we introduce the style, the style will become global style. A series of lifecycle methods provided by Taro can also be used within components. The entry component will have a render function that contains the page we need to render.
3.2.2 Page components
Once we have written an entry component, we are ready to write a series of pages. A normal page Component, which is also a React Component or Vue Component. If we reference a style file on a page, the style file becomes a page-level style. Similarly, a series of lifecycle methods provided by Taro can be used within pages. Note that React needs to import the basic components of Taro from @tarojs/ Component before using them. Vue can be used directly because we use vue-loader to analyze which base components the user is using.
3.2.3 Componentization
3.2.4 Life cycle
Let’s take a look at what life cycles we can use. Taking the page life cycle as an example, Taro’s life cycle is divided into two parts: the first part is the original framework life cycle method, and the second part is extended with some characteristic life cycle methods of small programs.
3.2.5. Component Library
React components need to be referenced before being used. Why? Whether it is Vue or React, you need to reference the Taro component library. The Taro component library uses the corresponding components of the applet directly on the application side. However, on the H5 side, there are only HTML tags and there is no applet specification component. Therefore, we used Web Components to realize the component library corresponding to the micro channel applets specification.
3.2.6, API
Next, take a look at the API. In the applet, all the apis of the applet specification are fully supported in Taro. First, we need to import taro objects from the @tarojs/taro package. Then we can call the applet API in the taro object. What exactly does the Taro API do? In fact, the applet side will directly call the API at the bottom of the applet, but additional to these APIS do Promise operations. On the H5 side, because these apis are not available, we Mock most of the commonly used applets specification apis.
3.2.7, Ref
Finally, to introduce Ref, Taro Next’s Ref is a little different from the current Taro implementation. If we use the Ref syntax of the framework, we will get the HTMLElement from Taro. We can obtain some node attributes or methods of HTMLElement, and even set the style to update the view. However, if we want to obtain some node-related information, we can only obtain the rendering node corresponding to the view layer through the method of obtaining the real rendering node provided by the small program, and then obtain its size information.
3.3 Project advancement
Next is an introduction to the project progression.
3.3.1 State management
As our project grows larger, we may introduce some status management tools. In the current Taro architecture, if we want to use Redux or Mobx, we need to implement compatibility with these status management tools and the Taro rendering mechanism before users can install and use compatible packages.
3.3.2 Style tools
Now look at the style tool, which also mentioned that there is no style isolation between components. If we want to use style scopes, we can use CSS Modules. CSS Modules can be configured directly in the Taro configuration file. Linaria can be used if you are a fan of CSS in JS. The details are covered in the documentation, so we won’t expand on them here.
3.3.3 render HTML
3.4. Multi-side development
After we develop a project, there may be some work to adapt to multi-terminal, so let’s talk about multi-terminal development.
3.4.1 Native applet pages/components
The first is to use native applet pages/components. Using a native applet page is as simple as configuring the corresponding route in the entry configuration file and pointing to those native applet pages. If you need to use native applet components, you can use them in the page by configuring the usingComponents field in the page configuration.
3.4.2 Cross-platform development
There is an environment variable called TARO_ENV in Taro. Developers can use it to make conditional judgments and use different logic according to different platforms. But if we have a lot of ifs and else in our code, it’s really hard to maintain.
3.4.3 Cross-framework development
Finally, we will introduce cross-framework development. Considering that some users may need to develop components that can be used in React and Vue, we also provide a jquery-like script for users to write cross-framework components. We can then use these components in React and Vue together.
3.5. Performance optimization
After developing a project, maybe we will do some performance optimization work, so let’s talk about performance optimization.
3.5.1 Taro’s optimization of setData
First, Taro’s optimization of setData is introduced. The first point is that Taro Next’s setData is the smallest granularity setData. Consider the following scenario: if we want to setData a large list, when we are developing native applets, we often worry about whether we will setData some redundant data into the view layer. However, in Taro Next, we will do a Hydrate operation for this data first, to identify the data that is really used in rendering, and finally only setData that is used in rendering, thus greatly reducing the amount of setData.
The second point is to update by path. During the update, we will compare the old and new Taro DOM Tree, and then use the path update syntax of the small program to setData the result of diff, which can also greatly reduce the amount of setData.
3.5.2. Pre-rendering
In addition to discussing some of the performance enhancements provided by Taro itself, here are some of the tuning options provided by Taro to users. The first one is Prerender. Taro’s overall render flow should look something like the one on the left. React or Vue will render Taro’s DOM tree first, and a Hydrate operation will be performed on the Taro DOM tree within Taro to get data that can be setData, and finally setData to the view layer. If the DOM tree is very complex when we initialize it, then our setData volume will be very large and the page will appear briefly blank. Therefore, we provide a pre-render function, which users can use to pre-render a placeholder page, and then wait until the actual setData of the Taro DOM tree is complete before showing the page that can be truly interactive.
3.5.3, React
ShouldComponentUpdate, PureComponent, and React.Memo are all acceptable if the user is using React.
3.5.4 Optimization of long list
The next step is long list optimization. Long lists are a common performance bottleneck when we develop web applications, so we provide a VirtualList VirtualList component. The VirtualList component only renders items that are visible in the visual window, and those items that are outside the viewport are replaced by placeholder elements. This will limit the number of items we render and make scrolling through the list smoother.
3.5.5 volume optimization
Finally, let’s look at volume dependent optimization. Taro’s code will be packaged using Webpack, so the optimization tools in Webpack are available to us. Examples include code compression, tree-shaking, side-effects, etc. If a user still feels that their package is large, they can use the webpack-bundle-Analyzer plug-in to analyze their package dependencies and make more detailed optimizations.
Next, we’ll talk about subcontracting. If the user’s main package is large, you can split some subcontracting. The subcontracting function is fully supported in Taro Next. However, there is a problem here. By default, the subcontracted node_modules dependencies will be packed into the main package vendor.js. In this case, we can use splitChunks to make more detailed optimization and separate the subcontracted node_modules dependencies separately. Reduce the size of the main package further by placing the split files into the corresponding subpackages.
Four, principle analysis
After saying how to use Taro Next, I believe you have aroused some interest in Taro Next. Here we will explain some principles of Taro Next, including the implementation principle of small program and H5.
4.1. Design ideas
First introduce our design ideas in the small program. You can see that both React and Vue use the browser’s DOM and BOM API and then render to the browser. We can also implement a layer of DOM and BOM inside the applet to make these frameworks run on top of the applet.
4.2 DOM rendering scheme
But there is a problem here. Even if we get an Taro DOM tree, how do we get setData into the view layer? Since the applet does not provide the ability to create nodes dynamically, we need to consider how to render the Taro DOM tree dynamically using relatively static WXML. We use template splicing to recursively reference each other based on the DOM tree data structure provided by the runtime to render the corresponding dynamic DOM tree.
Let’s start with a simple view template example. Above is a view component template. First we need to write a view inside the template, and then list all its properties (all the properties are listed because the applet can’t add properties dynamically). The next step is to iterate over and render all the child nodes, which reference the mid-tier template first, and then the mid-tier template finds the component template based on the corresponding nodeName. By piecing together the template step by step in this way, we can render our dynamic DOM tree.
4.3 Adapt React
Here’s how to adapt React. React architectures include React Core, Reconcliers, and Renderers. However, the React DOM renderer is bulky and has a lot of compatibility code that would be too large to fit into a small program. So we want to implement a renderer ourselves, we can provide a hostConfig to connect to the Taro DOM API, so as to implement a small program renderer.
Take a look at the React rendering process as a whole. React will use the taro-React renderer, and then use the taro-Runtime createReactPage function to render the page into the taro DOM tree. We then do a Hydrate operation on the Taro DOM tree to get the data we need for setData and then setData and the view layer will concatenate all the templates based on this data to render the corresponding page.
4.4 Vue rendering process
Let’s take a look at the rendering flow of Vue. Since there is not a lot of redundant code on the Vue side, we can use it directly. From the taro runtime package, the createVuePage method should also be used to render pages into an Taro DOM tree, and setData should be applied to splitter these templates together in the view layer to render the corresponding pages.
4.5 Taro Next Small program side architecture
Next, take a look at the overall architecture of the Taro Next applets. First, the user’s React or Vue code will be webpacked through CLI. Second, we will provide the adaptors corresponding to React and Vue for adaptation during runtime, and then call the DOM and BOM API provided by us. Finally, the entire program is rendered to all the small program end above.
4.6 H5 Terminal architecture
Let’s take a look at the H5 architecture. Again, we need to package the user’s React or Vue code with Webpack. Then at runtime we need to do three things: The first thing we need to do is to implement a component library. The component library needs to be used by React, Vue and even more frameworks, so we used Stencil to implement a component library based on WebComponents and following the micro app specification. The second and third thing is that we need to implement a small program specification API and routing mechanism so that we can eventually run the entire program on the browser.
V. Summary and prospect
Finally, I would like to share a summary and outlook for today.
5.1,
The conclusion is divided into four points:
- First, we introduced the background of the reconstruction of Taro, which is to solve architectural problems and provide support for multiple frameworks.
- Taro Next introduces some new features, Taro Next is now more powerful, faster, and more flexible.
- It then describes how to use Taro Next for development practices.
- Finally, the whole realization principle of small program and H5 terminal is introduced.
5.2. Customized expansion
Next we will add the ability to customise the extension framework, making Taro an open multi-terminal framework. The background is that we are currently adapting Vue3, but we found that to adapt Vue3 we need to change a lot of the source code, and the source code is full of all kinds of conditional code for the framework. So we wanted to make Taro more open. The goal is to add support for the framework directly in the form of the Taro plugin without having to change the Taro source code.
New version of Taro3
The official release of Taro3 will be available in early July and will be available by the time this article is published.
5.4. Contact Information
Welcome to our Github for Issues and PR. If you want to cooperate or submit your resume, please contact us at email. To join the Taro official communication group, scan the qr code above. My recommendation for today is Hackers and Painters, which is Paul’s thoughts on technology and entrepreneurship. This is the end of today’s sharing, thank you!
Q: What do you need to pay attention to when upgrading from Taro 2.0.2 to Taro Next? Is the upgrade seamless?
A: Actually, there are some syntax that need to be modified, because we didn’t need to reference React before, but now to use React, we need to reference the React package first. If you use Vue, you also need to reference the Vue package. Then we will provide an update-related plug-in, which allows users to modify the current syntax and then upgrade seamlessly. Now, if you want to try it out, you can also refer to the upgrade guide in the documentation. There is not much syntax to change.
Do you have any SSR best practices based on the Taro React model? Is it an official release or a preview?
A: We haven’t done the related functions of SSR yet, we may do it later, and then the official version will be released on July 1st. Now it is the Xi version, and there are about two smaller versions to the official version.
Q: Ask JJ: Is my understanding correct? 3.0 will add ReactAdapter and VueAdapter at run time, instead of using the compile-time template AST to compile transformations. Can this sex run time be worse?
A: Yes, from A macro point of view, from A compiled framework to A run-time framework, now those compile-time operations are basically gone, and the performance will definitely be worse than the previous compile-time adaptation. But we thought that the hardware and the environment were going to get better, so we thought it was worth sacrificing a little bit of performance for a better user experience. And then we’ll move in the direction of the run-time framework.