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 push group, 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 article is the 68th session of the 9th Cross-end cross-stack – Front-end early chat, from the Tmall Genie IOT front end team pin sharing speech brief collated version (for the complete version of the demo, please see the video and PPT) :


I. Personal Profile

  • Hello, everyone, I am a pin from the IOT front end team of Tmall Genie. It is my great honor to have this opportunity to share with you our practical experience in cross-end development in the field of Internet of Things. I started front-end development in 2010 and worked in Ctrip, Dianping, elong and other companies successively. Have been engaged in IOT front-end work

Second, the directory


3. Cross-end scenarios and characteristics


1. Cross-end scenario


  • When it comes to the Internet of Things, you may first think of a variety of devices. Our cross-terminal scenario requires running on a variety of devices. Therefore, there may be some differences between this and what we shared before, mainly on mobile phones.

1.1 End (iot devices) : mobile phone, speaker, TV, watch and car…

1.2 Operating System: IOS, Android, Linux, RTOS…

1.3 Technology stack: ReactNative, H5, Cube applets

  • Cube is probably the thing you will be stranger, in the iot scenarios was quite small program with a combination of rn, it was quite developed, DSL is a small program, but the rendering is through the cube to do view rendering, we summarize down across the side of the scene, so some characteristics of fragmentation is extremely serious, The number of ends, screens, and technology stacks we cover is huge and growing.

2. Cross-end characteristics

  • Our application is characterized by strong interaction, multiple functions and multiple devices, and its business scenarios are different. Our technology precipitation cycle in different equipment fields is relatively long, so we need to view the development of our application from a relatively long time line.

3. Application display


  • Here are some of the apps that we are running online at the moment. Those apps are not available on other screens for the time being. Here are only some apps for mobile

4. Cross-end scheme and thinking


  • Because of the serious fragmentation, we mainly solve the problem of how to improve the efficiency, otherwise this area will definitely be a black hole of human input.

1. How to reduce cost and improve efficiency?


1.1 Cross-end development scheme: mainly solve the problem of fragmentation of technology stack

1.2 Visual construction: Mainly solve the problems of flat fragmentation function and UI fragmentation

2. What are the cross-end implementation methods?


2.1 Code Compilation

  • Currently the industry is more popular, most of the framework adopted a way
  • Implementation principle: a DSL is compiled into a DSL for each platform, and then some runtime support framework is combined to achieve cross-end.

2.2 Cross-platform parsers

  • Is a parsing engine that defines a DSL and then implements this DSL on various operating systems to achieve cross-ends. The most famous ones are the Web and Flutter

2.3 Cloud rendering client display

  • Rendering in the cloud, the client is just as a display, with the improvement of network speed, as well as the arrival of the cloud era and inorganic era, adopt a scheme, the industry is mainly in some mobile games have some relevant practice.

3. Is 100% span feasible?


3.1 Code Compilation Scheme:

  • Those of you who have done code compilation know that the syntactic capabilities of different languages are not equal, and it is generally difficult and impossible to achieve 100% cross-end by compilation

3.2 Cross-platform Parser:

  • Regardless of the performance resource footprint and cost, this solution is very promising to achieve 100 percent cross-end implementation. But now is it’s a pity to remove our standard operation system, actually there are still some super side, these super end it carries some of the role of the operating system, but it does not provide the operating system so that a complete development ability, such as now the most popular small program, it is actually a kind of constrained environment. In this constrained environment, it may be difficult for these resolvers to achieve 100% of their capabilities.

3.3 Cloud Rendering

  • Principle theoretically with this scheme is a more perfect expansion project, because when you run in the cloud, we can fully use the same technology stack, rendering it after issued to the device to display, but limited to at present is the popularity of 5 g, as well as some environmental factors, the present stage can only make some exploration and outlook.

4. Being realistic, which cross-end solution should we choose?


  • Based on the analysis, we have chosen the first method which is code compilation

5. Which DSL is selected as the development DSL?


5.1 How to Choose?

  • Depending on the team, which side of the business you’re targeting, and the technical background of the people on the team

5.2 Our choices

  • The main technology station of our team is actually the React technology stack, and the biggest side we put is actually small programs. Tmall Genie APP and Tmall Genie speaker are integrated with alipay small program container, so small program is the largest end we put. In order to share the ecology of small programs, and we open a development system to three parties, is also the development system of small programs
  • Our solution: React and dual DSL development of small programs

6. How to maximize cross-end reuse?


7. How to get rid of the burden of history and continuously upgrade the cross-end solution?


  • When we want to develop an application, its life cycle is relatively long, longer than some iterations of the technology war, we need to consider how to make our application can follow the upgrade of the technology stack to constantly update our stack, rather than tied to a framework

8. Our cross-end architecture solution


  • This is a simple illustration of our approach to module management. We developed a module management system to manage our source code and compile modules of code for various platforms.

5. Key technical points


1. Cross-end basic components


The base component is the smallest component that is integral to the view layer that you are developing your application from. Components are generally provided by the platform itself. For base components, our main job is really to smooth out the differences between base components on each end and platform.

1.1 Layout Components

  • Common layout components: View, Text
  • We can compile a large number of different layout components into view and text components, and then combine them with some of their default styles to implement rich semantic tags in HTML.

1.2 Functional Components

  • Common function components: Image, Video, Input, Canvas, Map……
  • These components is each component has some special functions, now actually contrast down each platform provided by these functional components are about the same, the main difference is that a functional components of its name, its properties on some differences, for these components we mainly do is to compare the various platforms components, to go with them.

2. Cross-end templates


2.1 Instruction Template

  • An instruction template is a set of instructions, such as attributes or tags, that are defined on an XML-like basis to achieve limited logical capabilities, such as simple expressions, loop judgments, and small programs

2.2 JS language hybrid template


  • JS language mixed template, is in the string or XML in the use of special characters for segmentation, the retrieval syntax mixed in, so that the template is almost complete retrieval ability, JSX belongs to this type of template

2.3 Comparison of two Templates

  • From the template level alone, the expression ability of the language-mixed template is definitely much greater than that of the instruction template, but in terms of the result rendered by combining the template and data, in fact, the ability of the two is equivalent
  • In fact, we can almost equate the two templates with the result rendered by the template combined with the data, and the expression ability of the instruction template, because if it is a subset of the JS language mixed template, in fact, the JS mixed template is equivalent to the instruction template, plus some additional JS logic to achieve the equation
  • The language blend template, which renders the data equivalent to the instruction template, plus I preprocess the data to render through an extra JS logic, and then render. Based on this equation, we can compile the template by compilation.
  • Because the way of compilation is actually very open, for the way of interaction between the two templates, here we introduce the way we adopt by raising bubbles, which will be a language mixed template, separating it into an instruction template and a preprocessor function, as shown in the figure below


  • This diagram is a simple illustration of how to compile a JSX template into an instruction template and a preprocessor
  • For the sake of the above overview, we have omitted many of these intermediate nodes, leaving only some of the key nodes. Babel traverses the tree of nodes, essentially walking through each node in depth, operating on each node at two times, entry and exit.
  • When we bubble the template, we configure the instruction template for the target we want to compile, and what syntax is supported, so that when we split the supported syntax into the specified template, we do not support the syntax into the handler function. The specific process is that when we enter the root node, we will hang three stacks on the state of the root node, one is the scope stack, one is the supported syntax stack and the unsupported syntax stack.
  • And then for each of the following nodes, we’re going to look at its exit and see if the current node and its parent are all syntaxes that we support, or if they’re all syntaxes that we don’t support. If it’s the same type as its parent, then we’re going to keep iterating. When traversal to a node, we found that, for example, it is that we support the syntax of the current node, and it’s parent is we don’t support syntax, or is he the current node is we don’t support syntax, his parent node is our support of grammar, we will push the current node to the corresponding a root node so we just created on the stack, A node of the same kind as our parent node is then popped up from another stack and mounted to the parent node, bubbling in turn. So our way through this bubble, after traversal, we separated the whole node tree is a tree is supported we specify template syntax node tree, a tree is we don’t support the syntax of the node tree, does not support the syntax of the node tree is actually we separate the data and processing functions.
  • This is just the core of the process, there are more details of the operation, such as its own instructions, template syntax specific syntax details are different. Just like uni-app, there are some differences in the syntax of different templates, and there is also a transformation for the supported syntax nodes.

3. Cross-end style


3.1 Alignment of basic style capabilities

  • For example, in applets or h5, if you have the same style sheet, the syntax of the style above might be a name or something, it might be a little bit different.

3.2 Basic style ability complement

  • Depending on the platform, some styles may be missing, but we can make up for this by, for example, converting native or JS capabilities or other default styles

3.3 Style inheritance, selector and other advanced functions

  • The way we did it was part of the basic ability to complement it and the styles, and then we didn’t select the styles and continued to use inheritance and selectors
  • We’ve experimented with styles in RN to support things like style inheritance and selectors, but because this would cause the number of styles on component nodes to explode, and it would be impossible to compress the data transfer by StyleSheet, So there was a huge increase in the amount of data in the channel and there was a significant decrease in performance, so we abandoned that, and in our case we basically just smoothed out the basic styles, and then we did styles in a non-selective, non-inherited way,

4. Cross-end component model


4.1 Life Cycle

4.2 Data to view rendering mode

4.3 Listening mode of View events

4.4 Component Reference Mode

  • This part is mainly in the following life cycle, data to view rendering, event listening, component reference and other aspects of different platforms. Here a piece of treasure elder brother just uni – app when there are some introduction, there is actually some of the detail of the processing, this involves the compilation is not much, is in order to support the runtime can do some simple extraction screeding compilation, then most of the functions are at run time to realize, that would not be doing a detailed introduction. At present, some open source cross-end frameworks, in fact, this piece actually have implementation, if interested students can find some open source frameworks to see the implementation of this piece.

5. Cross-end application model


  • The application model is similar, but the points to be smoothed out are a little different. As we have emphasized before, in fact, in order not to be bound to a framework, so that our application can continue to follow the iteration of technology as we develop, our different modules may adopt different technical solutions to achieve cross-end

6. Source code organization


6.1 Small and Medium-sized Projects

  • For small and medium-sized projects, you can use YARN Workspace or Lerna to manage the code. It is actually in the same code repository, divided into different modules through folders. Each module can have its own scaffolding and file dependencies. It is possible to publish a separate NPM package and put all modules in a single repository, which is actually manageable for small and medium-sized projects

6.2 Large-scale Projects

  • Features: The number of people modules will grow very large, and its time will continue for a long time
  • Organization: It is managed like a Git group, where each module is an independent Git repository.

Six, summarized


1. There is no good plan, only the most suitable plan


  • According to our business scenario, the characteristics of various aspects to consider
  • For example, what side are you going to cross, what is the technology stack on those side? And then according to the technology stack for each division, see how to, and then mainly on which side, first experience to ensure that the end, this will affect your choice of DSL as a development state of DSL you some technical tendency may be to end up, there are some tilt, and your ability is exactly at each end, In fact, it involves whether your whole solution is written and run everywhere or learned once, developed in the same way everywhere, and selected different technical solutions according to some background characteristics of your project team.

7. Team introduction


1. Recruitment requirements


1.1 responsibilities

  • Tmall Genie APP front part, Tmall Genie small program
  • The establishment of tmall Life Internet of Things platform.
  • Tmall Genie speakers, watches, TVS, cars and other devices in the IOT part of the front-end work

1.2 Existing technology direction

  • Multi-terminal multi-screen technology
  • Visual construction
  • Micro front-end
  • AIOT man-machine interaction

1.3 Recruitment

  • Senior Front End Engineer
  • Front End technical specialist

2. Join us

3. The conclusion

This article is formatted using MDNICE