[译]Vue.js 结合 Firestore 实际应用

Vue.js 结合 Firestore 实际应用 作者: Lukas van Driel | 译:永无止晋 原文地址:https://www.smashingmagazine.com/2018/04/vuejs-firebase-firestore/ 你想做一个网站或者APP,竟然没有服务器?竟然没有数据库?竟然没有域名?你还不会后端技术?那都不是事儿!本文讲解如何利用 Firestore 配合 vue.js 做一个“八卦”网站。 ps: 访问 firebase 控制台需要“蓝灯”等网络代理 Firestore 是 Google Firebase 的一种新的数据存储方式(目前处于测试阶段),它以 Firebase 实时数据库为基础,且增加了一些漂亮的功能。在本文中,我们将使用 Vue.js 和 Firestore 建立一个网站。 假设你想制作一个新的产品(例如下一个 Twitter ,Facebook 或 Instagram )。 首先,你要制作本产品的原型或最小可行产品,即 MVP(Minimum Viable Product), 这样尽可能快地构建应用程序的核心,以便你可以将其展示给用户获取反馈并分析使用情况。这样用最短的时间完成,后续也可以快速迭代。 开始之前,我们先来给这个产品起一个厉害的名字,我们就叫它 “Amazeballs” 。 下面是我预想的设计: Amazeballs 的定位是—–一个与朋友们分享生活中的“八卦”的应用。网站分为两部分,上面区域,我们放一个输入表单用来发表你的“八卦”,下面用来展示好友们的“八卦”。 构建一个 MVP,你需要能够快速实现功能,随后可以灵活的添加和更改功能的工具。Amazeballs 的技术选型为 Vue.js( JavaScript 渲染框架),并用 Firebase(by […]

新世纪Nerv战士 – 京东首页补完计划

回想17年的京东首页改版,从上线到现在竟然已经过去了四个多月。这四个多月,除了不曾中断的日常维护需求,对首页孜孜不倦的优化工作,更多的是那些与拖延症抗争的日夜:是今天写,还是等好好休憩回味后再动手?很明显,在这几十上百个日夜里,我基本都选择了第三个选项:不折腾了,先休息吧。现在想起来,关于那一个月白加黑五加二加班生活的印象已经渐渐模糊。到现在依然能清晰记着的,大概是最为深刻的记忆了。 16版的京东首页,在性能、体验、灾备策略等各方面都做到了极致。站在如此高大的巨人肩上,除了满满的自信,我们心里更怕扑街。毫无疑问,我们在接到改版需求的那一刻,立马就敲定了新首页的技术选型:妥妥的jQuery + SeaJS! 但很快,我们就发现这样一点都不酷。jQuery是2006年的框架了,SeaJS停止维护也已经四年。这些项目的诞生都是为了解决当时业界的一些痛点:比如jQuery最开始是为了方便程序员在页面中操作DOM,绑定事件等;SeaJS则是为了在浏览器中实现CMD规范的模块开发和加载。但在各种VirtualDOM框架横飞的现在,程序员已经很少会直接操作DOM元素,而模块的开发和加载也有早已有了别的方案。 就在这时,Nerv项目的作者提出了建议:“不然用Nerv来一发?”我记得,当时他脸上洋溢着淳朴的笑,Nerv也仅仅是部门内部的一个小项目。我们回想了首页这个业务,技术栈已经好几年未曾更新过,开发流程也不够理想。如果再不做出改变,明年的这个时候我们依然会面对一堆陈年老代码头疼不已。抱着试一试的心态,我们接受了他的提议。没想到,这个决定让首页从此摆脱了落后的技术架构,而Nerv现在也已经成长为GitHub上3k+ Star的热门项目。 Q: 为什么不使用React/Preact/Vue? A: 这三者都是前端圈子中相当流行的项目。React有完善的体系和浓厚的社区氛围,Preact有着羞涩的体积,Vue则使用了先进的html模板和数据绑定机制。但是,上边这三者都 无法兼容IE8。我们在经过相关数据的论证后,发现IE8的用户还是有一定的价值,这才最终激发了我们团队内部自己造轮子的想法。当然,在造轮子的过程中,我们也不忘向上面这些优秀框架的看齐。最终,Nerv在完美兼容React语法的同时,具有着出众的性能表现,在Gzip后也只占用9Kb的体积。 整体架构 在这次的项目中,我们基于上一年久经考验的前端体系(详细介绍),进行了升级: Athena前端工程化工具:团队自研的前端工程化工具。除了自动化编译、代码处理、依赖分析、文件压缩等常规需求,2.0版本还支持 基于npm的依赖管理,更加先进的引入、导出机制,还有 最新的es语言特性。 Athena管理平台:新增了 针对Nerv的项目模板,另外还有针对H5项目的特色模板可选。 Athena基础库与组件库:新增了基于jQuery+SeaJS的组件重构,全新升级的Nerv组件。 Athena模拟接口:除了已有的mock接口数据的能力,还支持 接口文档生成,便于沉淀项目接口信息。 Athena兜底接口:可以定时抓取线上接口的数据 生成兜底数据,还支持 接口数据校验,评估接口健康度。 Athena前端监控:我们部署了一系列的监控服务,对页面上的素材以及页面的完整功能进行监控。一旦图片尺寸/体积超限,某些特定的操作出现异常,或者接口成功率降低等异常情况,就会触发告警推送,开发者可以 实时收到告警信息。 Athena可视化报表:Athena可视化报表平台上对上报的数据都有 直观的展示。 开发模式 Athena2.0 1.0版本的Athena,基于vinyl-fs的流操作,或者说是类似于gulp的压缩、编译等等操作的任务流。而到了2017年,webpack早已在前端圈中流行。同行们也早已经习惯在项目中直接基于最新的语言特性去开发,在webpack.config.js加上一个babel-loader就可以完美支持新语法并完成打包。Athena 1.0背着太沉重的历史包袱,已经很难快速实现对babel转译的支持。所以在首页的开发前,我们将Athena升级到了全新的2.0版本。 一如既往,Athena会为项目提供init(初始化),serve(实时预览),build(编译),publish(发布)等功能。除此之外,由于2.0版本的Athena是基于webpack的,所以项目中可以 统一用npm来管理依赖,也可以直接 使用最新的ES语言特性来进行开发。 使用Athena2.0开发时,建议的文件架构如下: 前后端协作 我们依然是采用了 前后端分离的协作模式,由后端给出json格式的数据,前端拉取json数据进行渲染。对于大部分的组件来说,都会在constructor中做好组件的初始化工作,在componentDidMount的生命周期中拉取数据写入组件的state,再通过render函数进行渲染。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 […]

JDreact转H5—你需要做的兼容处理

前言 JDreact 像一位安静的女子独立窗前,明眸皓齿的样子让你不敢贸然向前,直到慢慢熟悉之后才会发现,原来她真是上得了厅堂,下得了厨房,写得了代码,查得出异常,既能支持安卓,又可兼容苹果,直到最后我们发现,她居然还可以转成 Web 端代码! 然而就像你心爱的姑娘一样,岂能让你这么容易追到手?今天咱们就来谈谈怎么追女孩!呸,不对!怎么把 JDreact 顺利的转成 H5 代码! 你准备好了吗? 相信你手头已经有一套千锤百炼的 JDreact 代码了!啥?你还没有?快去看看我之前写的文章《与JDReact的第一次亲密接触——加油卡项目总结》,呀!别走啊!即使不想看也没关系!你可以把 JDreact 想象成 React 代码,毕竟两者的语法还是有些类似的,如果也不知道 React ,那也没关系,留意一下呗,万一以后用到了呢! 转化步骤 我们先来看看 JDreact 转化成 H5 代码的主要步骤: 其中的注意事项,我们缓缓道来: 1.修改 config.js 配置文件: 执行完第 1、2 步骤之后,在生成的依赖文件中,找到 web 文件夹下的 config.js 配置文件,根据下面注释修改

其中,entry、publicPath 是需要根据业务代码进行配置的,其他参数可以使用默认值。 2.调用后台数据接口 JDreact 中访问后台接口的方法需要修改为 Jsonp 的方式。具体方法已经在修改 jsbundles 文件夹下的 web.js 后缀文件中给出,但是需要注意的是 Jsonp 中参数 appid 的获取。 首先,登录京东 API开放平台 […]

Vue拖拽组件开发实例

为什么选择Vue? 主要原因:对于前端开发来说,兼容性是我们必须要考虑的问题之一。我们的项目不需要兼容低版本浏览器。项目本身也是一个数据驱动型的。加之,Vue本身具有以下主要特性: 使用虚拟DOM; 轻量级框架; 高效的数据绑定; 灵活的组件系统; 完整的开发生态链。 这就是我们为什么选择Vue框架的一些原因。 为什么要封装成一个Vue组件? 主要目的是可提高代码的复用性和可维护性。 复用性:组件化后,一些样式和逻辑均通过配置参数的方式去差异化体现,所以参数的可配置性提高了组件的复用率和灵活性。 可维护性:组件化后,组件内部的逻辑只对组件负责,外部的逻辑只通过配置参数适配,所以提高了代码的逻辑清晰度,可以快速定位代码出现问题的地方。 组件化搭建页面图示: 上图可看出,在Vue中,所谓组件化搭建页面,简单来说,页面实际上是由一个个功能独立的组件搭建而成。这些组件之间可以组合、嵌套,最终形成了我们的页面。 组件构成 下面是一个完成的组件构成:

开发Vue移动拖拽组件为例 拖拽原理 手指在移动的过程中,实时改变元素的位置即top和left值,使元素随着手指的移动而移动。 拖拽实现 开始拖动时:获取到接触点相对于整个视图区的坐标clientX,clientY;获取元素距离视图上侧和左侧的距离 initTop,initLeft;计算接触点距离元素上侧和左侧的距离 elTop = clientY – initTop, elLeft = clientX – initLeft; 拖动过程中:通过 currTop = clientY – elTop, currLeft = clientX – elLeft 实时获取元素距离视图上侧和左侧的距离值,并赋值给元素,使元素跟着手指的移动而动起来; 拖动结束,定位元素。 Vue中的实现 使用Vue,最大的不同之处是我们几乎不去操作DOM,要充分利用Vue的数据驱动来实现拖拽功能。本例中,我们只需在垂直方向上拖动元素,所以只需考虑垂直方向的移动即可。 上图中,通过data中的dragList渲染拖拽区域列表,代码如下:

假设我们将元素从位置1拖至位置3,本质上是数组的顺序发生了改变。这就有必要提一下Vue的最大特性:数据驱动。 所谓的数据驱动就是当数据发生变化时,通过修改数据状态,使用户界面发生相应的改变,开发者不需要手动的去修改DOM。 Vue的数据驱动是通过MVVM这种框架来实现的,MVVM框架主要包含3个部分:Model、View、Viewmodel。 – Model:数据部分; […]

漫谈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 […]

© 2018 JDC. All Rights Reserved.