Vivo mall front-end architecture upgrade-multi-end unified exploration, practice and outlook

I. Introduction

This article will introduce the multi-end unified exploration and practice of vivo mall in the front-end dimension as a whole.

From multi-end value, why do multi-end unification, how to meet multi-end business needs, practice and innovation, we will explain everything we have done in multi-end unification concise and straightforward.

2. What value does multi-end exploration bring to vivo mall

The multi-end value can be reflected in two aspects: technical architecture upgrade and human resources release.

1. Comprehensive upgrade of technical architecture

From

To

We have achieved the unification of technical architecture solutions. Through unification, the development cost and maintenance cost are greatly reduced. At the same time, it has high reuse and high efficiency.

2. Release a lot of human resources

The unification of the technical architecture scheme provides strong technical support and achievable guarantee for the horizontal expansion of the business.

The figure below is the ratio of development manpower input after using the new technical architecture.

As can be seen from the figure above, considerable development resources have been released through the upgrade of the technical architecture. Let the released development resources do more valuable things.

3. Why do we want to do multi-end unification

You may have questions, but what is multi-end unification?

Here I will sell a key point first, let's not talk about unity, let's talk more about it. What is multi-end? I think everyone can talk about it.

Regarding multi-terminal, I drew a picture as follows:

As you can see from the above figure, offline, pc, wap, APP, WeChat official account, WeChat applet, etc., each can be called a terminal. Knowing the meaning of multi-end, now we look back at multi-end unification.

A complete multi-terminal unification should include the unification of the following aspects

• Multi-end unification of big front-end [front-end + client]
• Multi-end unification of the server
• Multi-terminal unification of business

Here, we only discuss the multi-end unification of the front end.

From the PC browser, to the mobile browser, to APP embedding, to various small programs, to the server and client. A prosperous ecology is like a hundred schools of thought contending, and a hundred flowers blossom. However, behind the prosperity, the challenges to front-end engineers are increasing day by day.

We undertake more and more terminals, and new terminals continue to appear, such as small programs and fast applications. Front-end engineers fall into the following doll trap:

1. Existing code and new code should be adapted to new end development scenarios
2. The code that has been adapted to the new end development scenario becomes the existing code
3. Existing code and new code should be adapted to new end development scenarios
4. cycle...

We hope to solve this problem, and hope to achieve a set of technical architecture scheme [code] that can cover the current end and the future end.

In layman's terms, we hope to achieve the capabilities shown in the following figure:

In this context of front-end development, multi-end unified emerges. It is a future trend in the front end, and it is also a good medicine to solve the above doll trap.

Fourth, how to meet the increasing demand for multi-terminal business

With the passage of time, the business of small terminals has gradually become more important, especially the WeChat small program of vivo mall.

The business side's requirements have two points, as follows:

The first point: Make the core functions of the existing vivo mall WeChat applet consistent with the mall H5 functions.

The second point: the subsequent iteration of the version, the small terminal and the H5 terminal are synchronized.

The reality is: the existing mall WeChat applet, its version iteration is already behind the mall H5 version .

We compare the purchase process videos of the new and old versions of the Mini Program to give everyone a more intuitive experience.

Old Mall Mini Program: Video >>

New Mall Mini Program: Video >>

The difference between the two can be seen from the above two videos, and the challenge we face is great.

According to the requirements of the business side, what we need to do is to solve the above two points, add one point, there are three points in total, as shown below:

• The first point: in the shortest time, the basic functions and processes of the mall H5 will be implemented on the WeChat applet

• The second point: to achieve high reuse and efficiency when the functions of the subsequent mini-program and H5 versions are synchronized.

• The third point: consider in advance the implementation of other business scenarios in the future, and do a good job of scalability and multi-terminal reusability.

Driven by business, we conducted technical research, demo verification, and mvp verification. Finally, under comprehensive consideration, the uni-app multi-terminal architecture was adopted to solve the above two difficulties.

To mention here, a good business-driven model is roughly as shown in the following figure:

Through the business to promote the optimization and change of technology, in the process of repeated application, real-time feedback for improvement, and finally return to the business. In this process, technology and business have formed a benign closed loop.

NOW. The rest is to practice.

5. What practices and innovations have we done

A famous saying goes like this: Practice is the only criterion for testing truth . It is true that behind the winners are hard work and persistence that you can't see.

1. Practice

In the course of practice, there are many factors to be considered, as listed below:

1. How to convert the native code of existing small programs into multi-terminal project writing to ensure that the converted code is readable and controllable.
2. Part of the functional logic of the existing applet needs to be fully preserved, even the native api and logic of the applet, how can these coexist with multi-terminal projects?
3. How to reuse H5 code logic to the greatest extent in multi-terminal projects.
4. How to elegantly adapt the various components, design patterns, engineering, and tool methods of H5 to multi-terminal projects.
5. and many more...

So how do we deal with these factors?

We can use a picture to summarize as a whole, as shown below:

Here is how we deal with these factors.

2. Code conversion

How to convert the native code of existing small programs into multi-terminal project writing to ensure that the converted code is readable and controllable?

We use the open source converter miniprogram-to-uniapp to do the conversion, and then manually solve the mismatch problem during the conversion process. The solution is so simple and unpretentious. Maybe everyone thinks the solution is simple. But behind choosing this solution, we made a detailed evaluation, including a WeChat exchange with the author of the open source converter. In the process of communicating with the author, we learned about the past, present and future of the converter. Under the circumstances, this was a suitable and correct solution.

3. Code coexistence

Part of the functional logic of the existing applet needs to be preserved intact, even the native api and logic of the applet, how can these coexist with multi-terminal projects?

We achieve natural isolation through reasonable catalog division of the project, as shown in the following figure:

We put some codes that are not yet compatible with multiple terminals into the platforms directory. At the same time, we will use conditional compilation to isolate platforms that cannot be converted to multi-terminals. As shown below:

4. Multiplexing and adapting h5

Reuse is about a lazy word. If it can be reused directly, reuse it decisively. Do not make secondary adjustments to ensure that it is highly consistent with H5.

Adaptation is about adapting to changes. We don't need to change the H5 code. We only need to make an adaptation layer for them, such as adapting H5 routing, some incompatible components, and even adapting to window. Location is fine.

From the solutions introduced above, we can realize that the core secret of dealing with these factors is the following two sentences:

The first sentence: adjust measures to local conditions and find a balance.

Second sentence: Improve reuse and reduce changes.

5. Innovation

There is a saying that goes like this: Greatness is conceived in the ordinary . Putting it here, let us put it another way, that is  , innovation breeds in practice .

In the course of practice, we have solved many problems. In the process of solving the problem, we made some happy innovations.

• vuex innovation

This innovation comes from a problem, the background of which is as follows:

The mall H5 product detail page uses vuex to manage data. When vuex is moved to the mini program product detail page, a phenomenon is found, as shown in the following animation:

From the above animation, we find that when using vuex, we click on product B from the detail page of product A to enter the product detail page of B. At this time, we click on the upper left corner to return to the product details page of A, and we will find that the product details page has changed to product B at this time, that is, the data of product A is gone.

This is a very big problem. After investigation, the reasons are as follows:

The default namespace of vuex is one, and the namespace cannot be added automatically. When using vuex for data management in the applet page, due to the applet page data mechanism, when you click to return, the page data uses the same vuex data, which leads to the above phenomenon.

Here, someone might say that in the onShow life cycle, refreshing the data will solve the problem. In fact, it is not. In this scenario, it is very unreasonable to refresh the data.

So how to solve it?

We know that after using vuex, the applet page data will have display problems after entering the same page multiple times. Subsequently, the group discussed, after comprehensive weighing, decided to continue to use vuex, and solve this problem by adding an adaptation layer to vuex.

Subsequently, the group had a discussion, and after a comprehensive balance, it was decided to continue to use vuex. This problem is solved by adding an adaptation layer to vuex.

First of all, let's see what happens after adding an adaptation layer to vuex and performing the above operations.

As shown in the animation below:

From the above animation, we can find that after adding an adaptation layer to vuex. Successfully solved the display problem of small program page data after using vuex, after entering the same page multiple times and clicking back.

How did we solve this problem?

Core solution: A more intelligent data flow management solution can be achieved by letting vuex support automatic expansion and automatic cancellation of namespace .

The core architecture diagram is as follows

By automatically generating the namespace in the store, it is ensured that the data of each page is retained after the same page is entered multiple times. When the page returns, the namespace association of the parent and child components is completed by dynamically collecting the namespace of the parent component.

Through the above technical solutions, we have solved the problems that existed when vuex was used in small programs. Here, the core architecture scheme has been given, and the specific implementation will not be described in detail.

6. Decoupling innovation

This innovation comes from a problem, the background of which is as follows:

We now have common, spike, and group product detail pages, and there will be other product detail pages later, so how do we reuse the business components in these detail pages?

Facing the above problems, everyone will have the following thoughts:

• Different pages, data processing in business components are different

• Different pages, the buried points in business components are different

• Different pages, there may be specific interface requests in business components

The above thoughts, everyone should have seen it. Reusing business components itself is a very difficult thing, and it is even more difficult if you want to completely decouple.

So, how do we decouple as much as possible?

We did the following:

1. Ensure the unification of buried points in the upstream, and achieve unification of buried points by designing the buried points at the component level.
2. At the component level, conditional judgments are made for specific interfaces.
3. The data of the business component is decomposed into source data and derived data. The source data is consistent at the vuex level, and the derived data is adapted accordingly in the business component according to the actual situation.
4. Renovate vuex to completely decouple the communication between business components and pages, and business components no longer need to know the vuex namespace of the page.

Students who have developed the mall project should all know that the logic of the selected bomb layer is very complicated. Here, we will take the selected bomb layer business component as an example to illustrate how we do business component reuse.

The following is the composition of the selected bomb layer components that have been reused:

├── components
│   ├── sku-number
│   ├── sku-product
│   ├── sku-service
│   ├── sku-spec
│   └── ...
├── index.js
├── index.scss
├── index.vue
├── mutation-types.js
└── track.js

We divide the data of the selected bomb layer components into source data and derived data. The source data is unified at the vuex level, as shown in the following figure:

We write a vuex for each detail page, and at the same time extract the same part into common-detail. After that, we process in vuex to ensure that the source data given by different pages is the same. These source data are to be passed to the business components.

As shown in the following code:

// 这是已选弹层业务组件
// 通过 @vivo/smartx 解耦组件和页面的通信
import { mapState, mapGetters, mapMutations, mapActions } from '@vivo/smartx'

// 获取源数据
computed: {
  ...mapState([
    'spuInfo',
    'skuInfo'
  ]),
  ...mapGetters([
    'price',
    'pageType'
  ]),
}

methods: {
  fn() {
    // 策略模式
  }
}

Through the above processing, similar business components can be well decoupled from different pages, thereby improving code reusability, maintainability and scalability.

The idea of ​​decoupling business components lies in:

There is no need to deliberately separate the data and the view completely. Through the source data and the derived data, the changed and the unchanging data are balanced, and then through the self-developed @vivo/smartx, the change will become an island, and the change will become an island. Isolated island.

Every innovation is a test. It always inadvertently gives you difficulties, and then forces you to break through yourself, thereby creating better things, repeating the cycle.

Finally, the multi-terminal WeChat mini program of vivo's official mall has been launched. You can click on the vivo official store to experience it.

Six, summary

In this article, we reviewed together the multi-end unified road of WeChat applets in vivo mall. From business needs, existence value, to technical practice and innovation, we hope to use technology to make the multi-end road more smooth.

Vivo official website mall front-end team