最新公告
  • 欢迎您光临起源地模板网,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入钻石VIP
  • vivo商城前端架构升级—多端统一探索、实践与展望篇

    正文概述 掘金(vivo互联网技术)   2020-11-24   1135

    一、引言

    本文将会从整体上介绍 vivo 商城在前端维度的多端统一探索和实践。

    从多端价值、为什么要做多端统一、如何满足多端业务需求、实践与创新,简洁直白的阐述我们在多端统一上所做的一切。

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

    多端的价值可以从技术架构升级和人力资源释放两个方面体现。

    1、技术架构全面升级

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

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

    我们实现了技术架构方案的统一。通过统一,极大的降低了开发成本、维护成本。同时具备高复用、高效率。

    2、释放大量人力资源

    技术架构方案的统一,对业务的横向扩张提供了强大的技术支持和可实现保障。

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

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

    从上图可以看出,通过技术架构的升级,释放了可观的开发资源。让释放的开发资源去做更多有价值的事情。

    三、我们为什么要做多端统一

    大家可能会有疑问,那就是多端统一是什么?

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

    关于多端,我画了个图,如下所示:

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

    从上图可以看到,线下、pc、wap、APP、微信公众号、微信小程序等,每一个都可以称为一个端。知道了多端的含义,现在,我们再回头看多端统一。

    完整的多端统一,要包含以下几个方面的统一

    这里,我们只讨论前端的多端统一。

    从 PC 浏览器,到移动端浏览器、到 APP 内嵌,再到各个小程序,再到服务端、客户端。繁荣的生态,犹如百家争鸣,百花齐放。然而,繁荣的背后,对前端工程师的挑战,则与日俱增。

    我们承接的端越来越多,新的端不断的出现,如小程序、快应用等。前端工程师陷入了如下套娃陷阱:

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

    我们希望解决这种问题,希望做到一套技术架构方案【代码】,可以覆盖现在的端和未来的端。

    通俗点说,我们希望做到如下图所示的能力:

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

    在这种前端开发背景下,多端统一出现了。它是前端的一个未来趋势,它也是解决上面套娃陷阱的一剂良药。

    四、如何满足日益增加的多端业务需求

    随着时间的推移,各小程序端业务被逐渐重视起来,尤其是 vivo 商城微信小程序。

    业务方的述求有两点,如下所示:

    **第一点:**让现有 vivo 商城微信小程序的核心功能和商城 H5 功能保持一致。

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

    而现实是:现有的商城微信小程序,其版本迭代已经较大的落后商城 H5 版本了

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

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

    根据业务方的述求,我们需要做的事情在解决上面两点的情况下,增加一点,共有三点,如下所示:

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

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

    通过业务来推动技术的优化和改变,在反复应用的过程中,实时反馈改进,最后回报给业务。在这个过程中,技术和业务形成了良性闭环。

    NOW. 剩下的事情,就是落地实践了。

    五、我们的多端做了哪些实践和创新

    有句名言是这样说的:实践是检验真理的唯一标准。诚然,成功者的背后,有你看不见的努力和坚持。

    1、实践

    在实践过程中,要考虑的因素很多,列举如下:

    我们可以用一张图整体概括下,如下图所示:

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

    下面就介绍下我们是如何处理这些因素的。

    2、代码转换

    我们使用的是开源转换器 miniprogram-to-uniapp 来做的转换,然后再通过人工,去解决转换过程中不匹配的问题。解决方案就是这么朴实无华,也许大家觉得方案很简单,但是选择这个解决方案的背后,我们做了详细的评估,包括和该开源转换器的作者进行了微信交流。在和作者沟通交流的过程中,我们知道了该转换器的过去、现在和未来,在当时的情况下,这是一个合适且正确的解决方案。

    3、代码共存

    我们通过对项目进行合理的目录划分,来达到天然的隔离,如下图所示:

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

    我们把一些现在还不能适配多端的代码,统一放到 platforms 目录下。同时,我们会使用条件编译来将现在还不能转换成多端的平台隔离开。如下图所示:

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

    4、复用和适配 h5

    复用讲究的是一个懒字,能直接复用的就果断复用,不要做二次调整,保证和 H5 高度一致。

    适配讲究的是一个以不变应万变,我们不需要改动 H5 的代码,我们只需要为他们做一个适配层,如适配 H5 路由,一些不兼容的组件,甚至说适配 window.location 都可以。

    从上面介绍的解决方案中,我们可以体会到,处理这些因素的核心秘诀就是下面两句话:

    5、创新

    有句话是这样说的:平凡中孕育着伟大。放在这里,我们换个说法,那就是 实践中孕育着创新

    在实践的过程中,我们解决了很多问题。在解决问题的过程中,我们做出了一些令人高兴的创新。

    • vuex 创新

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

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

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

    这是一个非常大的问题,经过排查,发现原因如下:

    vuex 的 namespace 默认是一个,无法自动新增 namespace 。当在小程序页面里面使用 vuex 进行数据管理时,由于小程序页面数据机制,在点击返回时,页面数据使用的是同一个 vuex 的数据,从而导致了上面出现的现象。

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

    我们知道,小程序页面数据在使用 vuex 后,多次进入同一个页面后,返回会有展示问题。随后,组内进行了讨论,综合权衡后,确定继续用 vuex ,通过给 vuex 加一个适配层来解决这个问题。

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

    首先我们看下,在给 vuex 加一个适配层后,进行上面的操作,会是什么现象。

    如下动图所示:

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

    从上面的动图,我们可以发现,在给 vuex 加了一个适配层后。成功的解决了小程序页面数据在使用 vuex 后,多次进入同一个页面后,点击返回时,出现的展示问题。

    核心方案:通过让 vuex 支持自动扩展、自动注销 namespace,来做到更加智能化的数据流管理方案

    核心架构图如下所示

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

    通过在 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
    

    vivo商城前端架构升级—多端统一探索、实践与展望篇vivo商城前端架构升级—多端统一探索、实践与展望篇我们将已选弹层组件的数据分为源数据和派生数据,源数据通过 vuex 层面去统一,如下图所示:

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

    我们为每个详情页写一个 vuex ,同时将相同的部分抽离到 common-detail 中。之后,我们在 vuex 中进行处理,保证不同页面给出的源数据是相同的。这些源数据是要传到业务组件中的。

    如下代码所示:

    // 这是已选弹层业务组件
    // 通过 @vivo/smartx 解耦组件和页面的通信
    import { mapState, mapGetters, mapMutations, mapActions } from '@vivo/smartx'
    
    // 获取源数据
    computed: {
      ...mapState([
        'spuInfo',
        'skuInfo'
      ]),
      ...mapGetters([
        'price',
        'pageType'
      ]),
    }
    
    methods: {
      fn() {
        // 策略模式
      }
    }
    

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

    通过上面的处理,就可以将类似的业务组件很好的从不同页面中解耦出来,从而提高代码的复用性、可维护性以及可扩展性。

    这种解耦业务组件的思想就在于:

    每一次创新,都是一次考验,它总是不经意间给你出难点,然后逼迫你,去突破自己,从而创造出更好的东西,循环往复。

    最后,多端架构的 vivo 官方商城微信小程序已经上线了。大家可以点击vivo官方商城体验一下哦。

    六、总结

    本文我们一起回顾了, vivo 商城微信小程序的多端统一之路。从业务需要,存在价值,到技术实践与创新,我们希望用技术让多端之路能够更加平坦。


    起源地下载网 » vivo商城前端架构升级—多端统一探索、实践与展望篇

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    模板不会安装或需要功能定制以及二次开发?
    请QQ联系我们

    发表评论

    还没有评论,快来抢沙发吧!

    如需帝国cms功能定制以及二次开发请联系我们

    联系作者

    请选择支付方式

    ×
    迅虎支付宝
    迅虎微信
    支付宝当面付
    余额支付
    ×
    微信扫码支付 0 元