漫谈Vue组件库开发

2017年是Vue.js大爆发的一年,React迎来了一个强有力的竞争对手,王者地位受到挑战(撰写此文时github上Vue与React的star数量已逼近)。我们团队这一年有十多个大型项目采用了Vue技术栈,在开发效率、页面性能、可维护性等方面都有不错的收效。 我们希望把这些项目中可复用的功能组件提取出来,给后续项目使用,以减少重复开发,提高效率,同时也为了致敬前端界“出一个框架,造一遍轮子”的行规, 一个基于Vue 2的移动端UI组件库被提上日程。 组件库的开发过程总的来说还是比较顺利的,这里与大家分享一些问题与思考。 脚手架选择 尽管我们团队的这些Vue技术栈项目的脚手架大都使用的是webpack,在为组件库选择脚手架的时候我们还是在webpack与Rollup中犹豫了一下。 Rollup看起来更适合组件库的开发,它把所有模块构建在一个函数内,执行效率更高,它支持Tree Shaking,只打包需要的代码,输出文件更小(webpack后来也支持了)。但综合考虑之后,我们还是选择了webpack作为打包工具。首先,按照规划,demo演示和文档页面也在这个脚手架中,所以对代码分割、热加载等功能是有需求的,而这方面能力Rollup远不及webpack。另外,这个组件库由多人开发维护,基于现有webpack脚手架开发成本更低、效率更高。选择webpack,让我们可以更专注于造轮子。 打包 即便选择了webpack作为打包工具,我们也并不希望这个库的使用场景局限在webpack项目中,通过AMD/CMD方式、甚至通过script标签直接引用等场景都应该得到支持。为了达到这个目的,我们需要在webpack配置文件中设置输出格式,需要配置的选项是output.libraryTarget,有以下可选值: “var”(默认值)输出为一个变量

“this” 输出为this的一个属性

“window” 输出为window对象的一个属性

“global” 输出为global对象的一个属性

“commonjs” 输出为exports 的一个属性

“commonjs2” 以module.exports形式输出

“amd” 输出为AMD模块 “umd” 暴露给所有模块定义,允许它和CommonJS/AMD/全局变量一起工作 很显然,我们需要把output.libraryTarget的值设为“umd”,以使我们的库可以工作在各种场景下。 另一个与库打包有关的设置项是output.umdNamedDefine,在output.libraryTarget 设为umd,且output.library 也设置了的情况下,把此选项值设为true,将会为AMD模块命名。

Vue组件库只提供组件,Vue文件自身需要组件库使用者在项目中自行引入,库中无需打包。所以我们可以把Vue加到externals中。

这样Vue就不会被打包。不过,有个问题,就是用script标签的形式引用Vue的时候,挂在window上的变量名是“Vue”,而不是我们需要的”vue”,因此使用时会报vue未定义的错误。 还好,webpack的externals配置项支持传入一个对象,可以为不同导出形式指定不同名称。所以下面这种写法可以解决这个问题。 组件类型 规划中的Vue组件库包含组件(Component)、指令(Directive)和过滤器(Filter)三种类型的存在。 比较特殊的是模态弹窗类(Modal)组件,如Dialog、Toast等等。页面中可能存在很多个Modal,而很多场景下用户的行为只会触发其中一部分,如果把所有可能弹出的Modal(特别是异步的、结构内容复杂的Modal)全部写在页面上,是否妥当?对于多页面应用,每个页面都写一遍或者再封装一层组件是否繁琐而冗余?这个问题在知乎上引发过讨论,尤大(Vue.js作者尤雨溪)本人在参与讨论时给出建议,组件多层嵌套时,应该把Modal放在根组件里,然后在子组件里通过事件触发。在具体应用里,应该这么用,这符合Vue提倡的“状态驱动”。不过在组件库里,我们还是希望提供一种更便捷更通用的方式来使用Modal类型的组件。 参考了Element UI等优秀组件库的做法,我们把Modal类型的组件挂到了Vue.prototype上,使之成为Vue的实例方法,一次安装、全局调用。

因此,我们的组件库组件类型还包括“实例方法”。 组件CSS作用域 对于一个组件,我们希望它的CSS只作用于当前组件内的元素,所以我们给每个组件的Vue单页面文件的style标签加上了scoped属性。编译后,HTML标签会被自动添加一个随机生成的唯一属性 (比如 data-v-f3f3eg9) ,同时对应的CSS选择器也会增加同名的属性选择器(如.example[data-v-f3f3eg9]),这样组件内的 CSS […]

京东PLUS会员移动端改版实战

帝都的三月春暖花开、惠风和畅。在这美好的时节,我们接了个“大项目”——京东PLUS会员M端频道改版。 京东为向核心客户提供更优质的购物体验,推出了京东PLUS会员,包含购物回馈、自营运费补贴、畅读电子书、退换无忧、专属客服和专享商品等权益,全方位提升和丰富网购特权。PLUS会员项目作为国内第一个电商付费会籍项目,由传统的以流量为核心向以用户为核心进行转变,通过付费服务锁定高净值核心用户,向其提供更优质的购物体验,实现用户价值最大化。 这是京东很重要的一个产品,刘总在各种不同场合向雷军、刘中国、杨元庆、周鸿祎等知名人士赠予过PLUS终身荣誉会员。京东APP 6.0计划在首屏增加PLUS会员频道的入口,预计将会带来大量的新用户访问,我们以此为契机对PLUS会员频道M端进行了整体改版,以提升用户体验和转化率。 这个项目还是蛮有挑战的: 一方面要赶 APP 新版上线这个 deadline,另一方面需求提出的太晚,导致工期特别紧张。 业务逻辑本身比较复杂,近10种用户账户状态、实名认证情况、小白信用达标状态、自动续费开通状态、会员级别、后台配置等维度都将直接影响页面的楼层顺序、样式和逻辑。而根据需求,频道首页特别重,复杂程度远超现有页面和其他频道页。 我们前端和后端、产品团队身处异地,沟通成本较高。 项目页面既要作为京东M站的一部分适配主流手机的各种浏览器,同时还需要内嵌在 iOS/Android 平台的京东、京东金融、微信、手Q等 App 中,兼容性要求高。在项目后期,产品方对个别机型上的低版本浏览器也提出了兼容要求。 页面需要兼容一些其他团队提供的公共代码。 我们开工时,需求文档还未完全定稿,对需求了解的不充分和对业务逻辑复杂度认识不够,让我们一度非常被动,开发工作充满了挑战。为保证按时上线,我们顶着压力,加班加点,那段时间几乎连轴转。无论如何,我们拿下了这场硬仗,现在回过头来看,还是感慨无限。这里记录一下这个项目开发中遇到的一些问题。 选型之坑 旧版采用的是前端开发静态页面,后端再套页面的开发模式,在这种模式下前端人员可发挥的空间受到了很大制约,也给后期的维护和二次开发工作带来了麻烦。于是,此次改版我们提出采用前后端分离模式开发,以明确前后端权责、提高开发效率,同时提高后期可维护性,这一方案得到了后端团队的支持。而难点在于这次是改版,并不是完全从零开始,所以一旦前后端分离,之前在view层面的很多业务逻辑就也要拿到前端来做,而我们团队作为一个公共部门并不熟悉他们的业务,这无疑进一步增加了我们的压力。 我们在前端采用了目前比较流行的 Vue.js 2.0 开发框架,脚手架工具和之前开发的很多项目一样,仍然选择了京东前端自己开发的 JDF,而当时的 JDF 版本尚不支持解析 Vue 模板文件,所以我们使用了 Vue.js 的独立构建模式,也就是在页面上直接引入完整版的 Vue.js 文件(包含模板编译器),模板的编译在浏览器端完成,后来发现这给我们挖了个大坑。 项目测试阶段发现,iOS版京东APP 频道首页的打开速度明显慢于其他浏览器和 APP,每次进入页面都会首先渲染出 loading 浮层,之后3-4秒才渲染出页面的楼层。我们马上开始排查。在 APP 中调试还是比较困难的,而在调试方便的浏览器中又不存在这个问题,所以这个问题的排查,我们还真是下了一番功夫。 我们初步判断这不是常规的因为请求多、资源数据量大、JS逻辑等原因造成的问题,因为这些问题一旦存在必然影响不止一个浏览器,且通过浏览器性能监控并未发现明显异常情况。 我们和测试团队利用抓包工具对 iOS版京东APP 中这个页面的资源请求情况进行了监测(这个阶段我们还踩了iOS 10.3 版本 https 请求抓包的坑,下文细说),也没有发现明显异常,基本印证了我们的判断。 另一方面,我们发现同一部 iPhone 的 Safari 浏览器和京东金融、微信、手机QQ等 APP 中页面加载速度都明显快于 […]

© 2018 JDC. All Rights Reserved.