关于前端:vivo商城前端架构升级多端统一探索实践与展望篇

一、引言

本文将会从整体上介绍 vivo 商城在前端维度的多端对立摸索和实际。

从多端价值、为什么要做多端对立、如何满足多端业务需要、实际与翻新，简洁直白的论述咱们在多端对立上所做的所有。

二、多端摸索为 vivo 商城带来了哪些价值

多端的价值能够从技术架构降级和人力资源开释两个方面体现。

1、技术架构全面降级

从

到

咱们实现了技术架构计划的对立。通过对立，极大的升高了开发成本、保护老本。同时具备高复用、高效率。

2、开释大量人力资源

技术架构计划的对立，对业务的横向扩张提供了弱小的技术支持和可实现保障。

下图是应用新的技术架构后的开发人力投入比。

从上图能够看出，通过技术架构的降级，开释了可观的开发资源。让开释的开发资源去做更多有价值的事件。

三、咱们为什么要做多端对立

大家可能会有疑难，那就是多端对立是什么？

这里我先卖个关子，先不谈对立，咱们来说说多端一词。多端是什么呢？想必大家都能说个八九不离十。

对于多端，我画了个图，如下所示：

从上图能够看到，线下、pc、wap、APP、微信公众号、微信小程序等，每一个都能够称为一个端。晓得了多端的含意，当初，咱们再回头看多端对立。

残缺的多端对立，要蕴含以下几个方面的对立

• 大前端【前端 + 客户端】的多端对立
• 服务端的多端对立
• 业务的多端对立

这里，咱们只探讨前端的多端对立。

从 PC 浏览器，到挪动端浏览器、到 APP 内嵌，再到各个小程序，再到服务端、客户端。凋敝的生态，犹如百家争鸣，百花齐放。然而，凋敝的背地，对前端工程师的挑战，则一劳永逸。

咱们承接的端越来越多，新的端一直的呈现，如小程序、快利用等。前端工程师陷入了如下套娃陷阱：

1. 现有代码、新代码要适配新的端开发场景
2. 曾经适配新的端开发场景的代码成为了现有代码
3. 现有代码、新代码要适配新的端开发场景
4. 循环 …

咱们心愿解决这种问题，心愿做到一套技术架构计划【代码】，能够笼罩当初的端和将来的端。

艰深点说，咱们心愿做到如下图所示的能力：

在这种前端开发背景下，多端对立呈现了。它是前端的一个将来趋势，它也是解决下面套娃陷阱的一剂良药。

四、如何满足日益减少的多端业务需要

随着工夫的推移，各小程序端业务被逐步器重起来，尤其是 vivo 商城微信小程序。

业务方的述求有两点，如下所示：

第一点：让现有 vivo 商城微信小程序的外围性能和商城 H5 性能保持一致。

第二点：后续版本迭代，小程序端和 H5 端同步进行。

而事实是：现有的商城微信小程序，其版本迭代曾经较大的落后商城 H5 版本了。

咱们用新老版本的小程序购买流程视频做比照，让大家有个较为直观的感触。

老版商城小程序：视频 >>

新版商城小程序：视频 >>

从下面两个视频能够看出两者的差别，咱们面临的挑战很大。

依据业务方的述求，咱们须要做的事件在解决下面两点的状况下，减少一点，共有三点，如下所示：

• 第一点：在最短的工夫内，将商城 H5 的基本功能和流程在微信小程序上实现进去
• 第二点：在后续小程序端和 H5 端版本性能同步迭代时，做到高复用，高效率。
• 第三点：提前思考将来其余端业务场景的落地，做好扩展性、多端复用性。

在业务驱动下，咱们进行了技术调研、demo 验证、mvp 验证。最终在综合思考下，采纳了 uni-app 多端架构来解决下面两个难点。

这里提一下，业务驱动的良好模式，大略如下图所示：

通过业务来推动技术的优化和扭转，在重复利用的过程中，实时反馈改良，最初回报给业务。在这个过程中，技术和业务造成了良性闭环。

NOW. 剩下的事件，就是落地实际了。

五、咱们的多端做了哪些实际和翻新

有句名言是这样说的：实际是测验真谛的唯一标准。诚然，成功者的背地，有你看不见的致力和保持。

1、实际

在实际过程中，要思考的因素很多，列举如下：

1. 现有小程序的原生代码如何转成多端我的项目写法，保障转换代码可读、可控。
2. 现有小程序的局部性能逻辑须要残缺保留，甚至是小程序原生 api 和逻辑，这些和多端我的项目如何共存。
3. 如何将 H5 的代码逻辑最大水平的复用到多端我的项目中。
4. 如何优雅将 H5 的各种组件、设计模式、工程化、工具办法适配到多端我的项目中。
5. 等等 …

那么咱们是如何解决这些因素的呢？

咱们能够用一张图整体概括下，如下图所示：

上面就介绍下咱们是如何解决这些因素的。

2、代码转换

现有小程序的原生代码如何转成多端我的项目写法，保障转换代码可读、可控？

咱们应用的是开源转换器 miniprogram-to-uniapp 来做的转换，而后再通过人工，去解决转换过程中不匹配的问题。解决方案就是这么朴实无华，兴许大家感觉计划很简略，然而抉择这个解决方案的背地，咱们做了具体的评估，包含和该开源转换器的作者进行了微信交换。在和作者沟通交流的过程中，咱们晓得了该转换器的过来、当初和将来，在过后的状况下，这是一个适合且正确的解决方案。

3、代码共存

现有小程序的局部性能逻辑须要残缺保留，甚至是小程序原生 api 和逻辑，这些和多端我的项目如何共存？

咱们通过对我的项目进行正当的目录划分，来达到人造的隔离，如下图所示：

咱们把一些当初还不能适配多端的代码，对立放到 platforms 目录下。同时，咱们会应用条件编译来将当初还不能转换成多端的平台隔离开。如下图所示：

4、复用和适配 h5

复用考究的是一个懒字，能间接复用的就果决复用，不要做二次调整，保障和 H5 高度一致。

适配考究的是一个以不变应万变，咱们不须要改变 H5 的代码，咱们只须要为他们做一个适配层，如适配 H5 路由，一些不兼容的组件，甚至说适配 window.location 都能够。

从下面介绍的解决方案中，咱们能够领会到，解决这些因素的外围秘诀就是上面两句话：

第一句：就地取材，找到均衡。

第二句：进步复用，升高改变。

5、翻新

有句话是这样说的：平庸中孕育着平凡 。放在这里，咱们换个说法，那就是  实际中孕育着翻新。

在实际的过程中，咱们解决了很多问题。在解决问题的过程中，咱们做出了一些令人高兴的翻新。

• vuex 翻新

这个翻新来源于一个问题，这个问题的背景如下：

商城 H5 商品详情页用  vuex 治理数据，在将 vuex 移到小程序商品详情页中时，发现一个景象，如下动图所示：

从下面动图中，咱们发现，在应用 vuex 时，咱们从 A 商品的详情页中点击 B 商品，进入 B 商品详情页。这时，咱们点击左上角返回 A 商品详情页，会发现，此时商品详情页曾经变成 B 商品，也就是说，A 商品的数据曾经没了。

这是一个十分大的问题，通过排查，发现起因如下：

vuex 的 namespace 默认是一个，无奈主动新增 namespace。当在小程序页面外面应用 vuex 进行数据管理时，因为小程序页面数据机制，在点击返回时，页面数据应用的是同一个 vuex 的数据，从而导致了下面呈现的景象。

这里，有人可能要说，在 onShow 生命周期外面，刷新数据，不就解决了吗。其实不然，在这种场景下，进行数据刷新是十分不合理的。

那么该如何解决呢？

咱们晓得，小程序页面数据在应用 vuex 后，屡次进入同一个页面后，返回会有展现问题。随后，组内进行了探讨，综合衡量后，确定持续用 vuex，通过给 vuex 加一个适配层来解决这个问题。

随后，组内进行了探讨，综合衡量后，确定持续用 vuex。通过给 vuex 加一个适配层来解决这个问题。

首先咱们看下，在给 vuex 加一个适配层后，进行下面的操作，会是什么景象。

如下动图所示：

从下面的动图，咱们能够发现，在给 vuex 加了一个适配层后。胜利的解决了小程序页面数据在应用 vuex 后，屡次进入同一个页面后，点击返回时，呈现的展现问题。

咱们是如何解决这个问题的呢？

外围计划：通过让 vuex 反对主动扩大、主动登记 namespace，来做到更加智能化的数据流治理计划。

外围架构图如下所示

通过在 store 中主动生成 namespace，保障了同一个页面进入屡次后，每个页面数据都是保留的。当页面返回时，通过动静收集父组件的 namespace，实现了父子组件的 namespace 关联。

通过下面的技术计划，咱们解决了 vuex 在小程序外面应用时，存在的问题。这里，外围架构计划曾经给出，具体实现，就不再细述了。

6、解耦翻新

这个翻新来源于一个问题，这个问题的背景如下：

咱们当初有一般、秒杀、拼团 商品详情页，前面还会有其余商品详情页，那么咱们如何复用这些详情页外面的业务组件呢？

面对下面的问题，大家会有以下思考：

• 不同页面，业务组件内的数据处理是有差异的
• 不同页面，业务组件内的埋点是不一样的
• 不同页面，业务组件内可能存在特定的接口申请

下面的这些思考，大家看过应该是有感触的，复用业务组件自身就是一件很艰难的事件，如果想彻底的解耦更是难上加难。

那么，咱们是如何做到尽可能解耦的呢？

咱们做了以下几点：

1. 在上游保障埋点对立，通过设计组件层面的埋点来达到埋点对立。
2. 在组件层面，对特定接口，进行条件判断。
3. 将业务组件的数据分解成源数据和派生数据，源数据在 vuex 层面保障统一，派生数据在业务组件内依据理论状况进行相应的适配。
4. 对 vuex 进行革新，让业务组件和页面的通信彻底解耦，业务组件不再须要晓得页面的 vuex 命名空间。

开发过商城我的项目的同学应该都分明已选弹层的逻辑是很简单的，这里就拿 已选弹层 业务组件做例子来说下咱们是如何去做业务组件复用的。

上面是目前曾经复用的已选弹层组件的组成：

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

咱们将已选弹层组件的数据分为源数据和派生数据，源数据通过 vuex 层面去对立，如下图所示：

咱们为每个详情页写一个 vuex，同时将雷同的局部抽离到 common-detail 中。之后，咱们在 vuex 中进行解决，保障不同页面给出的源数据是雷同的。这些源数据是要传到业务组件中的。

如下代码所示：

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

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

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

通过下面的解决，就能够将相似的业务组件很好的从不同页面中解耦进去，从而进步代码的复用性、可维护性以及可扩展性。

这种解耦业务组件的思维就在于：

不用刻意将数据与视图彻底拆散，通过源数据和派生数据, 均衡好变和不变的数据，再通过自研的 @vivo/smartx 将变到不变变成孤岛，将不变到变变成孤岛。

每一次翻新，都是一次考验，它总是不经意间给你出难点，而后逼迫你，去冲破本人，从而发明出更好的货色，周而复始。

最初，多端架构的 vivo 官网商城微信小程序曾经上线了。大家能够点击 vivo 官网商城体验一下哦。

六、总结

本文咱们一起回顾了，vivo 商城微信小程序的多端对立之路。从业务须要，存在价值，到技术实际与翻新，咱们心愿用技术让多端之路可能更加平坦。

vivo 官网商城前端团队