分别创建屏幕上边框，右边框，下边框，左边框安全距离： safe-area-inset-top， safe-area-inset-right， safe-area-inset-bottom， safe-area-inset-left 使用： iOS 11 padding-top: constant(safe-area-inset-top); padding-right: constant(safe-area-inset-right); padding-bottom: constant(safe-area-inset-bottom); padding-left: constant(safe-area-inset-left); iOS 11.2 beta及其后 padding-top: env(safe-area-inset-top); padding-right: env(safe-area-inset-right); padding-bottom: env(safe-area-inset-bottom); padding-left: env(safe-area-inset-left); 兼容性写法： padding-top: 10px; padding-top: constant(safe-area-inset-top); padding-top: env(safe-area-inset-top); 与calc合用： padding-top: 10px; padding-top: calc(10px + constant(safe-area-inset-top)); padding-top: calc(10px + env(safe-area-inset-top)); 终！使用sass@mixin： @mixin x-padding-bottom($val:0px) { padding-bottom: $val; padding-bottom: calc(#{$val / 2} + constant(safe-area-inset-bottom)); /* no */ padding-bottom: calc(#{$val / 2} + env(safe-area-inset-bottom)); /* no */ } 注意！！！ 1、默认值为0px，不是0，原因是calc不支持与0计算。 2、小程序单位为rpx，一般都会转换为rpx，但是calc不支持，所以不允许转换，保持px。 参考文档：苹果官方文档

最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 那么，当我们在讨论多端框架时，我们在谈论什么： 多端 笔者以为，现在流行的多端框架可以大致分为三类： 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： 开发迅速 复用前端生态 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS 缺点有： 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 [代码]JS[代码] 和 [代码]Native[代码] 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 3. JavaScript 编译型 这类框架就是我们这篇文章的主角们：[代码]Taro[代码]、[代码]WePY[代码] 、[代码]uni-app[代码] 、 [代码]mpvue[代码] 、 [代码]chameleon[代码]，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。 这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 [代码]react-native-web[代码], Weex 原生支持) 另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。 但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。 那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。 如果不管什么 DSL 都能接受，那就可以进入下一个环节： 生态 以下内容均以各框架现在（2019 年 3 月 11日）已发布稳定版为标准进行讨论。 开发工具 就开发工具而言 [代码]uni-app[代码] 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。 其它的框架都是使用 CLI 命令行工具，但值得注意的是 [代码]chameleon[代码] 有独立的语法检查工具，[代码]Taro[代码] 则单独写了 ESLint 规则和规则集。 在语法支持方面，[代码]mpvue[代码]、[代码]uni-app[代码]、[代码]Taro[代码] 、[代码]WePY[代码] 均支持 TypeScript，四者也都能通过 [代码]typing[代码] 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。 CSS 方面，所有框架均支持 [代码]SASS[代码]、[代码]LESS[代码]、[代码]Stylus[代码]，Taro 则多一个 [代码]CSS Modules[代码] 的支持。 所以这一轮比拼的结果应该是： [代码]uni-app[代码] > [代码]Taro[代码] > [代码]chameleon[代码] > [代码]WePY[代码]、[代码]mpvue[代码] [图片] 多端支持度 只从支持端的数量来看，[代码]Taro[代码] 和 [代码]uni-app[代码] 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），[代码]chameleon[代码] 少了头条小程序紧随其后。 但值得一提的是 [代码]chameleon[代码] 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。[代码]uni-app[代码] 则有一套独立的条件编译语法，这套语法能同时作用于 [代码]js[代码]、样式和模板文件。[代码]Taro[代码] 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。 在移动端方面，[代码]uni-app[代码] 基于 [代码]weex[代码] 定制了一套 [代码]nvue[代码] 方案 弥补 [代码]weex[代码] API 的不足；[代码]Taro[代码] 则是暂时基于 [代码]expo[代码] 达到同样的效果；[代码]chameleon[代码] 在移动端则有一套 SDK 配合多端协议与原生语言通信。 H5 方面，[代码]chameleon[代码] 同样是由多态协议实现支持，[代码]uni-app[代码] 和 [代码]Taro[代码] 则是都在 H5 实现了一套兼容的组件库和 API。 [代码]mpvue[代码] 和 [代码]WePY[代码] 都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。 所以最后一轮对比的结果是： [代码]chameleon[代码] > [代码]Taro[代码]、[代码]uni-app[代码] > [代码]mpvue[代码]、[代码]WePY[代码] [图片] 组件库/工具库/demo 作为开源时间最长的框架，[代码]WePY[代码] 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。 [代码]uni-app[代码] 则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起 [代码]WePy[代码] 也是完全不遑多让的。 [代码]Taro[代码] 也有官方维护的跨端 UI 库 [代码]taro-ui[代码] ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 [代码]Taro[代码] 有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。 而 [代码]mpvue[代码] 没有官方维护的 UI 库，[代码]chameleon[代码] 第三方的 demo 和工具库也还基本没有。 所以这轮的排序是： [代码]WePY[代码] > [代码]uni-app[代码] 、[代码]taro[代码] > [代码]mpvue[代码] > [代码]chameleon[代码] [图片] 接入成本 接入成本有两个方面： 第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 [代码]wxparse[代码]、[代码]echart[代码]、[代码]zan-ui[代码] 等）多是基于原生微信小程序框架语法写成的。目前看来 [代码]uni-app[代码] 、[代码]Taro[代码]、[代码]mpvue[代码] 均有文档或 demo 在框架中直接使用原生小程序组件/库，[代码]WePY[代码] 由于运行机制的问题，很多情况需要小改一下目标库的源码，[代码]chameleon[代码] 则是提供了一个按步骤大改目标库源码的迁移方式。 第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。 而对于两种接入方式 Taro 都提供了 [代码]taro convert[代码] 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。 所以这轮的排序是： [代码]Taro[代码] > [代码]mpvue[代码] 、 [代码]uni-app[代码] > [代码]WePY[代码] > [代码]chameleon[代码] 流行度 从 GitHub 的 star 来看，[代码]mpvue[代码] 、[代码]Taro[代码]、[代码]WePY[代码] 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。 [代码]uni-app[代码] 则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 [代码]uni-app[代码] 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。 所以从流行程度来看应该是： [代码]uni-app[代码] > [代码]Taro[代码]、[代码]WePY[代码]、[代码]mpvue[代码] > [代码]chameleon[代码] [图片] 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 从第三方贡献者数量来看，[代码]Taro[代码] 在这一方面领先，并且 [代码]Taro[代码] 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 [代码]omi[代码] 框架小程序部分也是基于 Taro 完成的。 [代码]WePY[代码] 在腾讯开源计划的加持下在这一方面也有不错的表现；[代码]mpvue[代码] 由于停滞开发了很久就比较落后了；可能是产品策略的原因，[代码]uni-app[代码] 在开源建设上并不热心，甚至有些部分代码都没有开源；[代码]chameleon[代码] 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。 那么这一轮的对比结果是： [代码]Taro[代码] > [代码]WePY[代码] > [代码]mpvue[代码] > [代码]chameleon[代码] > [代码]uni-app[代码] 最后补一个总的生态对比图表： [图片] 未来 从各框架已经公布的规划来看： [代码]WePY[代码] 已经发布了 [代码]v2.0.alpha[代码] 版本，虽然没有公开的文档可以查阅到 [代码]2.0[代码] 版本有什么新功能/特性，但据其作者介绍，[代码]WePY 2.0[代码] 会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 [代码]WePY[代码] 的表现。 [代码]mpvue[代码] 已经发布了 [代码]2.0[代码] 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，[代码]mpvue[代码] 要想在未来有作为首先要打消社区对于 [代码]mpvue[代码] 不管不顾不更新的质疑。 [代码]uni-app[代码] 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 [代码]uni-app[代码] 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。 [代码]chameleon[代码] 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有： 快应用和端拓展协议 通用组件库和垂直类组件库 面向研发的图形化开发工具 面向非研发的图形化页面搭建工具 如果 [代码]chameleon[代码] 把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来 [代码]chameleon[代码] 将大有可为。 [代码]Taro[代码] 的未来也一样值得憧憬。Taro 即将要发布的 [代码]1.3[代码] 版本就会支持以下功能： 快应用支持 Taro Doctor，自动化检查项目配置和代码合法性 更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 [代码]只能用 map 创造循环组件[代码] 一条 H5 打包体积大幅精简 同时 [代码]Taro[代码] 也正在对移动端进行大规模重构；开发图形化开发工具；开发组件/物料平台以及图形化页面搭建工具。 结语 那说了那么多，到底用哪个呢？ 如果不介意尝鲜和学习 DSL 的话，完全可以尝试 [代码]WePY[代码] 2.0 和 [代码]chameleon[代码] ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。 [代码]uni-app[代码] 和 [代码]Taro[代码] 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。而 [代码]mpvue[代码] 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 [代码]uni-app[代码] 。 当然，Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究，有空看代码，没空看提交： chameleon: https://github.com/didi/chameleon mpvue: https://github.com/Meituan-Dianping/mpvue Taro: https://github.com/NervJS/taro uni-app: https://github.com/dcloudio/uni-app WePY: https://github.com/Tencent/wepy (按字母顺序排序)

0. 前言 平时写CSS，感觉有很多多余的代码或者不好实现的方法，于是有了预处理器的解决方案，主旨是write less &do more。其实原生css中，用上css变量也不差，加上bem命名规则只要嵌套不深也能和less、sass的嵌套媲美。在一些动画或者炫酷的特效中，不用js的话可能是用了css动画、svg的animation、过渡，复杂动画实现用了js的话可能用了canvas、直接修改style属性。用js的，然后有没有想过一个问题：“要是canvas那套放在dom上就爽了”。因为复杂的动画频繁操作了dom，违背了倒背如流的“性能优化之一：尽量少操作dom”的规矩，嘴上说着不要，手倒是很诚实地[代码]ele.style.prop = <newProp>[代码]，可是要实现效果这又是无可奈何或者大大减小工作量的方法。 我们都知道，浏览器渲染的流程:解析html和css（parse），样式计算（style calculate），布局（layout），绘制（paint），合并（composite），修改了样式，改的环节越深代价越大。js改变样式，首先是操作dom，整个渲染流程马上重新走，可能走到样式计算到合并环节之间，代价大，性能差。然后痛点就来了，浏览器有没有能直接操作前面这些环节的方法呢而不是依靠js？有没有方法不用js操作dom改变style或者切换class来改变样式呢？ 于是就有CSS Houdini了，它是W3C和那几个顶级公司的工程师组成的小组，让开发者可以通过新api操作CSS引擎，带来更多的自由度，让整个渲染流程都可以被开发者控制。上面的问题，不用js就可以实现曾经需要js的效果，而且只在渲染过程中，就已经按照开发者的代码渲染出结果，而不是渲染完成了再重新用js强行走一遍流程。 关于houdini最近动态可点击这里 上次CSS大会知道了有Houdini的存在，那时候只有cssom，layout和paint api。前几天突然发现，Animation api也有了，不得不说，以后很可能是Houdini遍地开花的时代，现在得进一步了解一下了。一句话：这是css in js到js in css的转变 1. CSS变量 如果你用less、sass只为了人家有变量和嵌套，那用原生css也是差不多的，因为原生css也有变量： 比如定义一个全局变量–color（css变量双横线开头） [代码]:root { --color: #f00; } [代码] 使用的时候只要var一下 [代码].f{ color: var(--color); } [代码] 我们的html： [代码]<div class="f">123</div> [代码] 于是，红色的123就出来了。 css变量还和js变量一样，有作用域的： [代码]:root { --color: #f00; } .f { --color: #aaa } .g{ color: var(--color); } .ft { color: var(--color); } [代码] html： [代码] <div className="f"> <div className="ft">123</div> </div> <div className=""> <div className="g">123</div> </div> [代码] 于是，是什么效果你应该也很容易就猜出来了： [图片] css能搞变量的话，我们就可以做到修改一处牵动多处的变动。比如我们做一个像准星一样的四个方向用准线锁定鼠标位置的效果： [图片] 用css变量的话，比传统一个个元素设置style优雅多了： [代码]<div id="shadow"> <div class="x"></div> <div class="y"></div> <div class="x_"></div> <div class="y_"></div> </div> [代码] [代码] :root{ --x: 0px; --y: 0px; } body{ margin: 0 } #shadow{ width: 50%; height: 600px; border: #000 1px solid; position: relative; margin: 0; } .x, .y, .x_, .y_ { position: absolute; border: #f00 2px solid; } .x { top: 0; left: var(--x); height: 20px; width: 0; } .y { top: var(--y); left: 0; height: 0; width: 20px; } .x_ { top: 600px; left: var(--x); height: 20px; width: 0; } .y_ { top: var(--y); left: 100%; height: 0; width: 20px; } [代码] [代码]const style = document.documentElement.style shadow.addEventListener('mousemove', e => { style.setProperty(`--x`, e.clientX + 'px') style.setProperty(`--y`, e.clientY + 'px') }) [代码] 那么，对于github的404页面这种内容和鼠标位置有关的页面，思路是不是一下子就出来了 2. CSS type OM 都有DOM了，那CSSOM也理所当然存在。我们平时改变css的时候，通常是直接修改style或者切换类，实际上就是操作DOM来间接操作CSSOM，而type om是一种把css的属性和值存在attributeStyleMap对象中，我们只要直接操作这个对象就可以做到之前的js改变css的操作。另外一个很重要的点，attributeStyleMap存的是css的数值而不是字符串，而且支持各种算数以及单位换算，比起操作字符串，性能明显更优。 接下来，基本脱离不了window下的CSS这个属性。在使用的时候，首先，我们可以采取渐进式的做法： [代码]if('CSS' in window){...}[代码] 2.1 单位 [代码]CSS.px(1); // 1px 返回的结果是：CSSUnitValue {value: 1, unit: "px"} CSS.number(0); // 0 比如top：0，也经常用到 CSS.rem(2); //2rem new CSSUnitValue(2, 'percent'); // 还可以用构造函数，这里的结果就是2% // 其他单位同理 [代码] 2.2 数学运算 自己在控制台输入CSSMath，可以看见的提示，就是数学运算 [代码]new CSSMathSum(CSS.rem(10), CSS.px(-1)) // calc(10rem - 1px)，要用new不然报错 new CSSMathMax(CSS.px(1),CSS.px(2)) // 顾名思义，就是较大值，单位不同也可以进行比较 [代码] 2.3 怎么用 既然是新的东西，那就有它的使用规则。 获取值[代码]element.attributeStyleMap.get(attributeName)[代码]，返回一个CSSUnitValue对象 设置值[代码]element.attributeStyleMap.set(attributeName, newValue)[代码]，设置值，传入的值可以是css值字符串或者是CSSUnitValue对象 当然，第一次get是返回null的，因为你都没有set过。“那我还是要用一下getComputedStyle再set咯，这还不是和之前的差不多吗？” 实际上，有一个类似的方法：[代码]element.computedStyleMap[代码]，返回的是CSSUnitValue对象，这就ok了。我们拿前面的第一部分CSS变量的代码测试一波 [代码]document.querySelector('.x').computedStyleMap().get('height') // CSSUnitValue {value: 20, unit: "px"} document.querySelector('.x').computedStyleMap().set('height', CSS.px(0)) // 不见了 [代码] 3. paint API paint、animation、layout API都是以worker的形式工作，具体有几个步骤： 建立一个worker.js，比如我们想用paint API，先在这个js文件注册这个模块registerPaint(‘mypaint’, class)，这个class是一个类下面具体讲到 在html引入CSS.paintWorklet.addModule(‘worker.js’) 在css中使用，background: paint(mypaint) 主要的逻辑，全都写在传入registerPaint的class里面。paint API很像canvas那套，实际上可以当作自己画一个img。既然是img，那么在所有的能用到图片url的地方都适合用paint API，比如我们来自己画一个有点炫酷的背景(满屏随机颜色方块)。有空的话可以想一下js怎么做，再对比一下paint API的方案。 [图片] [代码]// worker.js class RandomColorPainter { // 可以获取的css属性，先写在这里 // 我这里定义宽高和间隔，从css获取 static get inputProperties() { return ['--w', '--h', '--spacing']; } /** * 绘制函数paint，最主要部分 * @param {PaintRenderingContext2D} ctx 类似canvas的ctx * @param {PaintSize} PaintSize 绘制范围大小(px) { width, height } * @param {StylePropertyMapReadOnly} props 前面inputProperties列举的属性，用get获取 */ paint(ctx, PaintSize, props) { const w = (props.get('--w') && +props.get('--w')[0].trim()) || 30; const h = (props.get('--h') && +props.get('--h')[0].trim()) || 30; const spacing = +props.get('--spacing')[0].trim() || 10; for (let x = 0; x < PaintSize.width / w; x++) { for (let y = 0; y < PaintSize.height / h; y++) { ctx.fillStyle = `#${Math.random().toString(16).slice(2, 8)}` ctx.beginPath(); ctx.rect(x * (w + spacing), y * (h + spacing), w, h); ctx.fill(); } } } } registerPaint('randomcolor', RandomColorPainter); [代码] 接着我们需要引入该worker： [代码]CSS && CSS.paintWorklet.addModule('worker.js');[代码] 最后我们在一个class为paint的div应用样式： [代码].paint{ background-image: paint(randomcolor); width: 100%; height: 600px; color: #000; --w: 50; --h: 50; --spacing: 10; } [代码] 再想想用js+div，是不是要先动态生成n个，然后各种计算各种操作dom，想想就可怕。如果是canvas，这可是canvas背景，你又要在上面放一个div，而且还要定位一波。 注意： worker是没有window的，所以想搞动画的就不能内部消化了。不过可以靠外面的css变量，我们用js操作css变量可以解决，也比传统的方法优雅 4. 自定义属性 支持情况 点击这里查看 首先，看一下支持度，目前浏览器并没有完全稳定使用，所以需要跟着它的提示：[代码]Experimental Web Platform features” on chrome://flags[代码]，在chrome地址栏输入[代码]chrome://flags[代码]再找到[代码]Experimental Web Platform features[代码]并开启。 [代码]CSS.registerProperty({ name: '--myprop', //属性名字 syntax: '<length>', // 什么类型的单位，这里是长度 initialValue: '1px', // 默认值 inherits: true // 会不会继承，true为继承父元素 }); [代码] 说到继承，我们回到前面的css变量，已经说了变量是区分作用域的，其实父作用域定义变量，子元素使用该变量实际上是继承的作用。如果[代码]inherits: true[代码]那就是我们看见的作用域的效果，如果不是true则不会被父作用域影响，而且取默认值。 这个自定义属性，精辟在于，可以用永久循环的animation驱动一次性的transform。换句话说，我们如果用了css变量+transform，可以靠js改变这个变量达到花俏的效果。但是，现在不需要js，只要css内部消化，transform成为永动机。 [代码]// 我们先注册几种属性 ['x1','y1','z1','x2','y2','z2'].forEach(p => { CSS.registerProperty({ name: `--${p}`, syntax: '<angle>', inherits: false, initialValue: '0deg' }); }); [代码] 然后写个样式 [代码]#myprop, #myprop1 { width: 200px; border: 2px dashed #000; border-bottom: 10px solid #000; animation:myprop 3000ms alternate infinite ease-in-out; transform: rotateX(var(--x2)) rotateY(var(--y2)) rotateZ(var(--z2)) } [代码] 再来看看我们的动画，为了眼花缭乱，加了第二个改了一点数据的动画 [代码]@keyframes myprop { 25% { --x1: 20deg; --y1: 30deg; --z1: 40deg; } 50% { --x1: -20deg; --z1: -40deg; --y1: -30deg; } 75% { --x2: -200deg; --y2: 130deg; --z2: -350deg; } 100% { --x1: -200deg; --y1: 130deg; --z1: -350deg; } } @keyframes myprop1 { 25% { --x1: 20deg; --y1: 30deg; --z1: 40deg; } 50% { --x2: -200deg; --y2: 130deg; --z2: -350deg; } 75% { --x1: -20deg; --z1: -40deg; --y1: -30deg; } 100% { --x1: -200deg; --y1: 130deg; --z1: -350deg; } } [代码] html就两个div: [代码] <div id="myprop"></div> <div id="myprop1"></div> [代码] 效果是什么呢，自己可以跑一遍看看，反正功能很强大，但是想象力限制了发挥。 自己动手改的时候注意一下，动画关键帧里面，不能只存在1，那样子就不能驱动transform了，做不到永动机的效果，因为我的rotate写的是 rotateX(var(–x2))。接下来随意发挥吧 最后 再啰嗦一次 关于houdini最近动态可点击这里 关于houdini在浏览器的支持情况 ENJOY YOURSELF!!!

写在前面 Comi 读 ['kəʊmɪ]，类似中文 科米，是腾讯 Omi 团队开发的小程序代码高亮和 markdown 渲染组件。有了这个组件加持，小程序技术社区可以开始搞起来了。 体验 [图片] 感谢【小程序•云开发】提供技术支持。 预览 [图片] Comi 基于下面的 5 个组件进行开发： prismjs wxParse remarkable html2json htmlparser 先看 Comi 使用，再分析原理。 使用 先拷贝 此目录 到你的项目。 js: [代码]const comi = require('../../comi/comi.js'); Page({ onLoad: function () { comi(`你要渲染的 md！`, this) } }) [代码] wxml: [代码]<include src="../../comi/comi.wxml" /> [代码] wxss: [代码]@import "../../comi/comi.wxss"; [代码] 简单把！ 在 omip 中使用 先拷贝 此目录 到你的项目。 js: [代码]import { WeElement, define } from 'omi' import './index.css' import comi from '../../components/comi/comi' define('page-index', class extends WeElement { install() { comi(`你要渲染的 md`, this.$scope) } render() { return ( <view> <include src="../../components/comi/comi.wxml" /> </view> ) } }) [代码] WeElement 里的 this 并不是小程序里的 this，需要使用 [代码]this.$scope[代码] 访问小程序 Page或 Component 的 this。 css: [代码]@import '../../components/comi/comi.wxss'; [代码] 原理 在开发 Comi 之前，我们进行了预研，是否有必要造这个轮子。 代码高亮预研 wxParse 只是用标签包括代码，并未处理代码转成 WXML，所以渲染出的代码是没有颜色 老牌的 highlightjs 没有 WXML 对应的方案 老牌的 highlightjs 对 JSX 高亮支持太差 prismjs 是 react 官方使用的高亮插件，对 JSX 支持高亮很好 prismjs 支持几乎所有的语言，并且支持自定义扩展语言 prismjs 拥有 Line Highlight 插件（目前还未移植到 Comi） 综合上面信息，决定基于 prismjs 二次开发。 markdown 渲染预研 wxParse 老牌的渲染组件，支持 markdown wxParse 内置的 showdownjs 不满足代码高亮的格式需求（比如语言种类也会生成一个标签，当然可以通过 wxss 隐藏） 小程序基础库 1.4.0 开始支持 [代码]rich-text[代码] 组件展示富文本，但是格式需要转成 json 高性能 remarkable，Facebook 和 Docusaurus 都在使用，支持 md 语法修改和扩展 [代码]<rich-text nodes="{{nodes}}" bindtap="tap"></rich-text> [代码] [代码]Page({ data: { nodes: [{ name: 'div', attrs: { class: 'div_class', style: 'line-height: 60px; color: red;' }, children: [{ type: 'text', text: 'Hello&nbsp;World!' }] }] }, tap() { console.log('tap') } }) [代码] 综合上面信息，放弃 rich-text，决定基于 wxParse + remarkable 二次开发，移除 showdownjs。Comi 需要 remarkable 的高性能和灵活性。markdown 会持久化存在 db， 在小程序内运行时转换成 wxml，所以对性能还是有一定要求。 劫持 prismjs tokens [代码]tokens: function(text, grammar, language) { var env = { code: text, grammar: grammar, language: language }; _.hooks.run('before-tokenize', env); env.tokens = _.tokenize(env.code, env.grammar); _.hooks.run('after-tokenize', env); for (var i = 0, len = env.tokens.length; i < len; i++) { var v = env.tokens[i] if (Object.prototype.toString.call(v.content) === '[object Array]') { v.deep = true this._walkContent(v.content) } } return env.tokens }, [代码] [图片] 这段代码增加 tokens 方法到 prismjs 中，原库自带的 prism.highlight 的会把 tokens 转成 html，因为我们的目标的 wxml，所以这里提前把 tokens 作为方法返回值。当然还做了一件事，就是扩展了 token item 的 deep 属性来决定是否需要继续向下遍历生成 wxml。 原始的 jsx: [代码]render() { const { tks } = this.data return ( <view class='pre language-jsx'> <view class='code'> {tks.map(tk => { return tk.deep ? <text class={'token ' + tk.type}>{ tk.content.map(stk => { return stk.deep ? stk.content.map(sstk => { return <text class={'token ' + sstk.type}>{sstk.content || sstk}</text> }) : <text class={'token ' + stk.type}>{stk.content || stk}</text> })}</text> : <text class={'token ' + tk.type}>{tk.content || tk}</text> })} </view> </view> ) } [代码] jsx 编译出生成的 wxml，把这段 wxml 嵌入到 wxparse 里: [代码]<!-- 千万 不要格式化下面的 wxml，不然 text 嵌套 text 导致换行全部出来了 --> <template name="wxParseCode"> <view class="pre language-jsx"> <view class="code"> <block wx:for="{{item.tks}}" wx:for-item="tk"> <block wx:if="{{tk.deep}}"><text class="{{'token ' + tk.type}}"><block wx:for="{{tk.content}}" wx:for-item="stk"><block wx:if="{{stk.deep}}"><text class="{{'token ' + sstk.type}}" wx:for="{{stk.content}}" wx:for-item="sstk">{{sstk.content || sstk}}</text> </block> <block wx:else><text class="{{'token ' + stk.type}}">{{stk.content || stk}}</text> </block> </block> </text> </block> <block wx:else><text class="{{'token ' + tk.type}}">{{tk.content || tk}}</text> </block> </block> </view> </view> </template> [代码] 这段 wxml 不能进行格式化美化，不然多出许多换行符，因为 text 嵌套 text 会保留换行符！！ 修改 wxparse 里的分支逻辑： [代码]<block wx:elif="{{item.tagType == 'block'}}"> <view class="{{item.classStr}} wxParse-{{item.tag}}" style="{{item.styleStr}}"> <block wx:if="{{item.tag == 'pre'}}"> <template is="wxParseCode" data="{{item}}" /> </block> <block wx:elif="{{item.tag != 'pre'}}" > <block wx:for="{{item.nodes}}" wx:for-item="item" wx:key=""> <template is="wxParse1" data="{{item}}" /> </block> </block> </view> </block> [代码] 当 [代码]item.tag[代码] 为 [代码]pre[代码] 的时候使用 wxParseCode 模板，数据传入 item。item 的数据从哪里来？ 先修改 md 渲染器为 Remarkable: [代码]} else if (type == 'md' || type == 'markdown') { var converter = new Remarkable() var html = converter.render(data) transData = HtmlToJson.html2json(html, bindName); } [代码] 使用上面的 prism.tokens 计算出代码片段的 tokens，用于 wxparse 的模板渲染： [代码]function transPre(transData) { transData.nodes.forEach((node, index) => { if (node.tag == 'pre') { var lan = 'markup' if (node.nodes[0].classStr) { lan = node.nodes[0].classStr.split(' ')[0].replace('language-', '') } var tks = prism.tokens(node.nodes[0].nodes[0].text, prism.languages[lan], lan) transData.nodes[index].tks = tks } }) } [代码] language- 支持多少种呢？目前 comi 默认支持： markup css clike javascript bash json typescript jsx tsx 默认使用的主题 css 是 okaidia。如果 comi 默认的配置不支持你的需求，你可以： 进 https://prismjs.com/download.html 这里自行下载 劫持 prismjs tokens 拷贝进你下载的 prismjs 里 把 prismjs 拷贝替换掉 comi 自带的 prismjs 精简 comi 使用流程 WXML 提供两种文件引用方式 import 和 include。和 import 不同，include 可以将目标文件除了 template 和 wxs 外的整个代码引入，相当于是拷贝到 include 位置，如： [代码]<!-- index.wxml --> <include src="header.wxml" /> <view>body</view> <include src="footer.wxml" /> [代码] [代码]<!-- header.wxml --> <view>header</view> [代码] [代码]<!-- footer.wxml --> <view>footer</view> [代码] comi 利用了 import 和 include 特性简化使用流程： comi.wxml [代码]<import src="./wxParse.wxml"/> <template is="wxParse" data="{{wxParseData:article.nodes}}"/> [代码] comi.js [代码]var WxParse = require('./wxParse.js'); module.exports = function comi(md, scope) { WxParse.wxParse('article', 'md', md, scope, 5); } [代码] comi.wxss [代码]@import './wxParse.wxss'; @import './prism.wxss'; [代码] 使用时，只需要 ： import [代码]comi.js[代码] include [代码]comi.wxml[代码] import [代码]comi.wxss[代码] 另外，在 omip 使用 comi 时候发现不会拷贝 include 的文件到 dist，发现 taro/omip 的正则没有去匹配 include 文件，所以，把： [代码]exports.REG_WXML_IMPORT = /<[import](.*)?src=(?:(?:'([^']*)')|(?:"([^"]*)"))/gi [代码] 改成: [代码]exports.REG_WXML_IMPORT = /<[import|inculde](.*)?src=(?:(?:'([^']*)')|(?:"([^"]*)"))/gi [代码] 搞定。 开始使用吧 Github Powered by Omi Team

随着各大前端框架的诞生和演变，[代码]SPA[代码]开始流行，单页面应用的优势在于可以不重新加载整个页面的情况下，通过[代码]ajax[代码]和服务器通信，实现整个[代码]Web[代码]应用拒不更新，带来了极致的用户体验。然而，对于需要[代码]SEO[代码]、追求极致的首屏性能的应用，前端渲染的[代码]SPA[代码]是糟糕的。好在[代码]Vue 2.0[代码]后是支持服务端渲染的，零零散散花费了两三周事件，通过改造现有项目，基本完成了在现有项目中实践了[代码]Vue[代码]服务端渲染。 关于Vue服务端渲染的原理、搭建，官方文档已经讲的比较详细了，因此，本文不是抄袭文档，而是文档的补充。特别是对于如何与现有项目进行很好的结合，还是需要费很大功夫的。本文主要对我所在的项目中进行[代码]Vue[代码]服务端渲染的改造过程进行阐述，加上一些个人的理解，作为分享与学习。 概述 本文主要分以下几个方面： 什么是服务端渲染？服务端渲染的原理是什么？ 如何在基于[代码]Koa[代码]的[代码]Web Server Frame[代码]上配置服务端渲染？ 基本用法 [代码]Webpack[代码]配置 开发环境搭建 渲染中间件配置 如何对现有项目进行改造？ 基本目录改造； 在服务端用[代码]vue-router[代码]分割代码； 在服务端预拉取数据； 客户端托管全局状态； 常见问题的解决方案； 什么是服务端渲染？服务端渲染的原理是什么？ [代码]Vue.js[代码]是构建客户端应用程序的框架。默认情况下，可以在浏览器中输出[代码]Vue[代码]组件，进行生成[代码]DOM[代码]和操作[代码]DOM[代码]。然而，也可以将同一个组件渲染为服务器端的[代码]HTML[代码]字符串，将它们直接发送到浏览器，最后将这些静态标记"激活"为客户端上完全可交互的应用程序。 上面这段话是源自Vue服务端渲染文档的解释，用通俗的话来说，大概可以这么理解： 服务端渲染的目的是：性能优势。 在服务端生成对应的[代码]HTML[代码]字符串，客户端接收到对应的[代码]HTML[代码]字符串，能立即渲染[代码]DOM[代码]，最高效的首屏耗时。此外，由于服务端直接生成了对应的[代码]HTML[代码]字符串，对[代码]SEO[代码]也非常友好； 服务端渲染的本质是：生成应用程序的“快照”。将[代码]Vue[代码]及对应库运行在服务端，此时，[代码]Web Server Frame[代码]实际上是作为代理服务器去访问接口服务器来预拉取数据，从而将拉取到的数据作为[代码]Vue[代码]组件的初始状态。 服务端渲染的原理是：虚拟[代码]DOM[代码]。在[代码]Web Server Frame[代码]作为代理服务器去访问接口服务器来预拉取数据后，这是服务端初始化组件需要用到的数据，此后，组件的[代码]beforeCreate[代码]和[代码]created[代码]生命周期会在服务端调用，初始化对应的组件后，[代码]Vue[代码]启用虚拟[代码]DOM[代码]形成初始化的[代码]HTML[代码]字符串。之后，交由客户端托管。实现前后端同构应用。 如何在基于[代码]Koa[代码]的[代码]Web Server Frame[代码]上配置服务端渲染？ 基本用法 需要用到[代码]Vue[代码]服务端渲染对应库[代码]vue-server-renderer[代码]，通过[代码]npm[代码]安装： [代码]npm install vue vue-server-renderer --save [代码] 最简单的，首先渲染一个[代码]Vue[代码]实例： [代码] // 第 1 步：创建一个 Vue 实例 const Vue = require('vue'); const app = new Vue({ template: `<div>Hello World</div>` }); // 第 2 步：创建一个 renderer const renderer = require('vue-server-renderer').createRenderer(); // 第 3 步：将 Vue 实例渲染为 HTML renderer.renderToString(app, (err, html) => { if (err) { throw err; } console.log(html); // => <div data-server-rendered="true">Hello World</div> }); [代码] 与服务器集成： [代码] module.exports = async function(ctx) { ctx.status = 200; let html = ''; try { // ... html = await renderer.renderToString(app, ctx); } catch (err) { ctx.logger('Vue SSR Render error', JSON.stringify(err)); html = await ctx.getErrorPage(err); // 渲染出错的页面 } ctx.body = html; } [代码] 使用页面模板： 当你在渲染[代码]Vue[代码]应用程序时，[代码]renderer[代码]只从应用程序生成[代码]HTML[代码]标记。在这个示例中，我们必须用一个额外的[代码]HTML[代码]页面包裹容器，来包裹生成的[代码]HTML[代码]标记。 为了简化这些，你可以直接在创建[代码]renderer[代码]时提供一个页面模板。多数时候，我们会将页面模板放在特有的文件中： [代码]<!DOCTYPE html> <html lang="en"> <head><title>Hello</title></head> <body> <!--vue-ssr-outlet--> </body> </html> [代码] 然后，我们可以读取和传输文件到[代码]Vue renderer[代码]中： [代码]const tpl = fs.readFileSync(path.resolve(__dirname, './index.html'), 'utf-8'); const renderer = vssr.createRenderer({ template: tpl, }); [代码] Webpack配置 然而在实际项目中，不止上述例子那么简单，需要考虑很多方面：路由、数据预取、组件化、全局状态等，所以服务端渲染不是只用一个简单的模板，然后加上使用[代码]vue-server-renderer[代码]完成的，如下面的示意图所示： [图片] 如示意图所示，一般的[代码]Vue[代码]服务端渲染项目，有两个项目入口文件，分别为[代码]entry-client.js[代码]和[代码]entry-server.js[代码]，一个仅运行在客户端，一个仅运行在服务端，经过[代码]Webpack[代码]打包后，会生成两个[代码]Bundle[代码]，服务端的[代码]Bundle[代码]会用于在服务端使用虚拟[代码]DOM[代码]生成应用程序的“快照”，客户端的[代码]Bundle[代码]会在浏览器执行。 因此，我们需要两个[代码]Webpack[代码]配置，分别命名为[代码]webpack.client.config.js[代码]和[代码]webpack.server.config.js[代码]，分别用于生成客户端[代码]Bundle[代码]与服务端[代码]Bundle[代码]，分别命名为[代码]vue-ssr-client-manifest.json[代码]与[代码]vue-ssr-server-bundle.json[代码]，关于如何配置，[代码]Vue[代码]官方有相关示例vue-hackernews-2.0 开发环境搭建 我所在的项目使用[代码]Koa[代码]作为[代码]Web Server Frame[代码]，项目使用koa-webpack进行开发环境的构建。如果是在产品环境下，会生成[代码]vue-ssr-client-manifest.json[代码]与[代码]vue-ssr-server-bundle.json[代码]，包含对应的[代码]Bundle[代码]，提供客户端和服务端引用，而在开发环境下，一般情况下放在内存中。使用[代码]memory-fs[代码]模块进行读取。 [代码]const fs = require('fs') const path = require( 'path' ); const webpack = require( 'webpack' ); const koaWpDevMiddleware = require( 'koa-webpack' ); const MFS = require('memory-fs'); const appSSR = require('./../../app.ssr.js'); let wpConfig; let clientConfig, serverConfig; let wpCompiler; let clientCompiler, serverCompiler; let clientManifest; let bundle; // 生成服务端bundle的webpack配置 if ((fs.existsSync(path.resolve(cwd,'webpack.server.config.js')))) { serverConfig = require(path.resolve(cwd, 'webpack.server.config.js')); serverCompiler = webpack( serverConfig ); } // 生成客户端clientManifest的webpack配置 if ((fs.existsSync(path.resolve(cwd,'webpack.client.config.js')))) { clientConfig = require(path.resolve(cwd, 'webpack.client.config.js')); clientCompiler = webpack(clientConfig); } if (serverCompiler && clientCompiler) { let publicPath = clientCompiler.output && clientCompiler.output.publicPath; const koaDevMiddleware = await koaWpDevMiddleware({ compiler: clientCompiler, devMiddleware: { publicPath, serverSideRender: true }, }); app.use(koaDevMiddleware); // 服务端渲染生成clientManifest app.use(async (ctx, next) => { const stats = ctx.state.webpackStats.toJson(); const assetsByChunkName = stats.assetsByChunkName; stats.errors.forEach(err => console.error(err)); stats.warnings.forEach(err => console.warn(err)); if (stats.errors.length) { console.error(stats.errors); return; } // 生成的clientManifest放到appSSR模块，应用程序可以直接读取 let fileSystem = koaDevMiddleware.devMiddleware.fileSystem; clientManifest = JSON.parse(fileSystem.readFileSync(path.resolve(cwd,'./dist/vue-ssr-client-manifest.json'), 'utf-8')); appSSR.clientManifest = clientManifest; await next(); }); // 服务端渲染的server bundle 存储到内存里 const mfs = new MFS(); serverCompiler.outputFileSystem = mfs; serverCompiler.watch({}, (err, stats) => { if (err) { throw err; } stats = stats.toJson(); if (stats.errors.length) { console.error(stats.errors); return; } // 生成的bundle放到appSSR模块，应用程序可以直接读取 bundle = JSON.parse(mfs.readFileSync(path.resolve(cwd,'./dist/vue-ssr-server-bundle.json'), 'utf-8')); appSSR.bundle = bundle; }); } [代码] 渲染中间件配置 产品环境下，打包后的客户端和服务端的[代码]Bundle[代码]会存储为[代码]vue-ssr-client-manifest.json[代码]与[代码]vue-ssr-server-bundle.json[代码]，通过文件流模块[代码]fs[代码]读取即可，但在开发环境下，我创建了一个[代码]appSSR[代码]模块，在发生代码更改时，会触发[代码]Webpack[代码]热更新，[代码]appSSR[代码]对应的[代码]bundle[代码]也会更新，[代码]appSSR[代码]模块代码如下所示： [代码]let clientManifest; let bundle; const appSSR = { get bundle() { return bundle; }, set bundle(val) { bundle = val; }, get clientManifest() { return clientManifest; }, set clientManifest(val) { clientManifest = val; } }; module.exports = appSSR; [代码] 通过引入[代码]appSSR[代码]模块，在开发环境下，就可以拿到[代码]clientManifest[代码]和[代码]ssrBundle[代码]，项目的渲染中间件如下： [代码]const fs = require('fs'); const path = require('path'); const ejs = require('ejs'); const vue = require('vue'); const vssr = require('vue-server-renderer'); const createBundleRenderer = vssr.createBundleRenderer; const dirname = process.cwd(); const siteInfo = require('./../../core/siteinfo.js').get(); const env = siteInfo.env; let bundle; let clientManifest; if (env === 'development') { // 开发环境下，通过appSSR模块，拿到clientManifest和ssrBundle let appSSR = require('./../../core/app.ssr.js'); bundle = appSSR.bundle; clientManifest = appSSR.clientManifest; } else { bundle = JSON.parse(fs.readFileSync(path.resolve(__dirname, './dist/vue-ssr-server-bundle.json'), 'utf-8')); clientManifest = JSON.parse(fs.readFileSync(path.resolve(__dirname, './dist/vue-ssr-client-manifest.json'), 'utf-8')); } module.exports = async function(ctx) { ctx.status = 200; let html; let context = await ctx.getTplContext(); ctx.logger('进入SSR，context为： ', JSON.stringify(context)); const tpl = fs.readFileSync(path.resolve(__dirname, './newTemplate.html'), 'utf-8'); const renderer = createBundleRenderer(bundle, { runInNewContext: false, template: tpl, // （可选）页面模板 clientManifest: clientManifest // （可选）客户端构建 manifest }); ctx.logger('createBundleRenderer renderer：', JSON.stringify(renderer)); try { html = await renderer.renderToString({ ...context, url: context.CTX.url, }); } catch(err) { ctx.logger('SSR renderToString 失败： ', JSON.stringify(err)); console.error(err); } ctx.body = html; }; [代码] 如何对现有项目进行改造？ 基本目录改造 使用[代码]Webpack[代码]来处理服务器和客户端的应用程序，大部分源码可以使用通用方式编写，可以使用[代码]Webpack[代码]支持的所有功能。 一个基本项目可能像是这样： [代码]src ├── components │ ├── Foo.vue │ ├── Bar.vue │ └── Baz.vue ├── frame │ ├── app.js # 通用 entry(universal entry) │ ├── entry-client.js # 仅运行于浏览器 │ ├── entry-server.js # 仅运行于服务器 │ └── index.vue # 项目入口组件 ├── pages ├── routers └── store [代码] [代码]app.js[代码]是我们应用程序的「通用[代码]entry[代码]」。在纯客户端应用程序中，我们将在此文件中创建根[代码]Vue[代码]实例，并直接挂载到[代码]DOM[代码]。但是，对于服务器端渲染([代码]SSR[代码])，责任转移到纯客户端[代码]entry[代码]文件。[代码]app.js[代码]简单地使用[代码]export[代码]导出一个[代码]createApp[代码]函数： [代码]import Router from '~ut/router'; import { sync } from 'vuex-router-sync'; const Vue = require('vue'); const { createStore } = require('./../store'); import ElementUI from 'element-ui'; import vueScroll from 'vue-scroll'; import '~mstyle/ai-scan/src/assets/less/common.less'; import Frame from './index.vue'; import breastRouter from './../routers/breast'; import lungRouter from './../routers/lung'; import List from './../page/list/index.vue'; import DicomView from '~cmpt/dicom-view'; Vue.use(vueScroll); Vue.use(ElementUI); function createVueInstance(routes, ctx) { let siteinfo; if (ctx) { siteinfo = ctx.siteinfo; } else { siteinfo = window.SiteInfo; } const router = Router({ base: siteinfo.path, mode: 'history', routes: [routes], }); const store = createStore({ ctx }); // 把路由注入到vuex中 sync(store, router); const app = new Vue({ router, render: function(h) { return h(Frame); }, store, }); return { app, router, store }; } function createVueInstanceNoRouter(component, ctx) { const componentIns = Vue.extend(component); const store = createStore({ ctx }); const app = new Vue({ store, render: h => h(component), }); return { app, store }; } module.exports = function createApp(ctx) { // 通过typeof window是否为'undefined'判断当前是客户端还是服务端 // 针对不同页面创建不同的Vue实例 if (typeof window !== 'undefined') { // 客户端 if (/list/.test(window.location.pathname)) { return createVueInstanceNoRouter(List); } else if (/breast/.test(window.location.pathname)) { DicomView.init('image', 'imaging'); return createVueInstance(breastRouter); } else if (/lung/.test(window.location.pathname)) { DicomView.init('series', 'imaging'); return createVueInstance(lungRouter); } else if (/pacs/.test(window.location.pathname)) { DicomView.init('series', 'imaging'); return createVueInstance(pacsRouter); } else if (/esophagus/.test(window.location.pathname)) { return createVueInstance(esophagusRouter); } else { return void console.log('The path does not match any router rule'); // do nothing } } else { // 服务端 if (/list/.test(ctx.path)) { return createVueInstanceNoRouter(List, ctx); } else if (/lung/.test(ctx.path)) { return createVueInstance(lungRouter, ctx); } else if (/pacs/.test(ctx.path)) { return createVueInstance(pacsRouter); } else if (/esophagus/.test(ctx.path)) { return createVueInstance(esophagusRouter); } else if (/breast/.test(ctx.path)) { return createVueInstance(breastRouter, ctx); } else { return void console.log('The path does not match any router rule'); // do nothing } } } [代码] 注：在我所在的项目中，需要动态判断是否需要注册[代码]DicomView[代码]，只有在客户端才初始化[代码]DicomView[代码]，由于[代码]Node.js[代码]环境没有[代码]window[代码]对象，对于代码运行环境的判断，可以通过[代码]typeof window === 'undefined'[代码]来进行判断。 避免创建单例 如[代码]Vue SSR[代码]文档所述： 当编写纯客户端 (client-only) 代码时，我们习惯于每次在新的上下文中对代码进行取值。但是，Node.js 服务器是一个长期运行的进程。当我们的代码进入该进程时，它将进行一次取值并留存在内存中。这意味着如果创建一个单例对象，它将在每个传入的请求之间共享。如基本示例所示，我们为每个请求创建一个新的根 Vue 实例。这与每个用户在自己的浏览器中使用新应用程序的实例类似。如果我们在多个请求之间使用一个共享的实例，很容易导致交叉请求状态污染 (cross-request state pollution)。因此，我们不应该直接创建一个应用程序实例，而是应该暴露一个可以重复执行的工厂函数，为每个请求创建新的应用程序实例。同样的规则也适用于 router、store 和 event bus 实例。你不应该直接从模块导出并将其导入到应用程序中，而是需要在 createApp 中创建一个新的实例，并从根 Vue 实例注入。 如上代码所述，[代码]createApp[代码]方法通过返回一个返回值创建[代码]Vue[代码]实例的对象的函数调用，在函数[代码]createVueInstance[代码]中，为每一个请求创建了[代码]Vue[代码]，[代码]Vue Router[代码]，[代码]Vuex[代码]实例。并暴露给[代码]entry-client[代码]和[代码]entry-server[代码]模块。 在客户端[代码]entry-client.js[代码]只需创建应用程序，并且将其挂载到[代码]DOM[代码]中： [代码]import { createApp } from './app'; // 客户端特定引导逻辑…… const { app } = createApp(); // 这里假定 App.vue 模板中根元素具有 `id="app"` app.$mount('#app'); [代码] 服务端[代码]entry-server.js[代码]使用[代码]default export[代码] 导出函数，并在每次渲染中重复调用此函数。此时，除了创建和返回应用程序实例之外，它不会做太多事情 - 但是稍后我们将在此执行服务器端路由匹配和数据预取逻辑: [代码]import { createApp } from './app'; export default context => { const { app } = createApp(); return app; } [代码] 在服务端用[代码]vue-router[代码]分割代码 与[代码]Vue[代码]实例一样，也需要创建单例的[代码]vueRouter[代码]对象。对于每个请求，都需要创建一个新的[代码]vueRouter[代码]实例： [代码]function createVueInstance(routes, ctx) { let siteinfo; if (ctx) { siteinfo = ctx.siteinfo; } else { siteinfo = window.SiteInfo; } const router = Router({ base: siteinfo.path, mode: 'history', routes: [routes], }); const store = createStore({ ctx }); // 把路由注入到vuex中 sync(store, router); const app = new Vue({ router, render: function(h) { return h(Frame); }, store, }); return { app, router, store }; } [代码] 同时，需要在[代码]entry-server.js[代码]中实现服务器端路由逻辑，使用[代码]router.getMatchedComponents[代码]方法获取到当前路由匹配的组件，如果当前路由没有匹配到相应的组件，则[代码]reject[代码]到[代码]404[代码]页面，否则[代码]resolve[代码]整个[代码]app[代码]，用于[代码]Vue[代码]渲染虚拟[代码]DOM[代码]，并使用对应模板生成对应的[代码]HTML[代码]字符串。 [代码]const createApp = require('./app'); module.exports = context => { return new Promise((resolve, reject) => { // ... // 设置服务器端 router 的位置 router.push(context.url); // 等到 router 将可能的异步组件和钩子函数解析完 router.onReady(() => { const matchedComponents = router.getMatchedComponents(); // 匹配不到的路由，执行 reject 函数，并返回 404 if (!matchedComponents.length) { return reject('匹配不到的路由，执行 reject 函数，并返回 404'); } // Promise 应该 resolve 应用程序实例，以便它可以渲染 resolve(app); }, reject); }); } [代码] 在服务端预拉取数据 在[代码]Vue[代码]服务端渲染，本质上是在渲染我们应用程序的"快照"，所以如果应用程序依赖于一些异步数据，那么在开始渲染过程之前，需要先预取和解析好这些数据。服务端[代码]Web Server Frame[代码]作为代理服务器，在服务端对接口服务发起请求，并将数据拼装到全局[代码]Vuex[代码]状态中。 另一个需要关注的问题是在客户端，在挂载到客户端应用程序之前，需要获取到与服务器端应用程序完全相同的数据 - 否则，客户端应用程序会因为使用与服务器端应用程序不同的状态，然后导致混合失败。 目前较好的解决方案是，给路由匹配的一级子组件一个[代码]asyncData[代码]，在[代码]asyncData[代码]方法中，[代码]dispatch[代码]对应的[代码]action[代码]。[代码]asyncData[代码]是我们约定的函数名，表示渲染组件需要预先执行它获取初始数据，它返回一个[代码]Promise[代码]，以便我们在后端渲染的时候可以知道什么时候该操作完成。注意，由于此函数会在组件实例化之前调用，所以它无法访问[代码]this[代码]。需要将[代码]store[代码]和路由信息作为参数传递进去： 举个例子： [代码]<!-- Lung.vue --> <template> <div></div> </template> <script> export default { // ... async asyncData({ store, route }) { return Promise.all([ store.dispatch('getUserInfo'), store.dispatch('lung/getSeriesByStudyId', { studyId: route.params.id, aiEngine: route.params.aiEngine, }, { root:true }), store.dispatch('lung/getDicomViewConfig', { root:true }), store.dispatch('lung/getDialogWindow', { root:true }), ]); }, // ... } </script> [代码] 在[代码]entry-server.js[代码]中，我们可以通过路由获得与[代码]router.getMatchedComponents()[代码]相匹配的组件，如果组件暴露出[代码]asyncData[代码]，我们就调用这个方法。然后我们需要将解析完成的状态，附加到渲染上下文中。 [代码]const createApp = require('./app'); module.exports = context => { return new Promise((resolve, reject) => { const { app, router, store } = createApp(context.CTX); // 针对没有Vue router 的Vue实例，在项目中为列表页，直接resolve app if (!router) { resolve(app); } // 设置服务器端 router 的位置 router.push(context.CTX.url.replace('/imaging', '')); // 等到 router 将可能的异步组件和钩子函数解析完 router.onReady(() => { const matchedComponents = router.getMatchedComponents(); // 匹配不到的路由，执行 reject 函数，并返回 404 if (!matchedComponents.length) { return reject('匹配不到的路由，执行 reject 函数，并返回 404'); } Promise.all(matchedComponents.map(Component => { if (Component.asyncData) { return Component.asyncData({ store, route: router.currentRoute, }); } })).then(() => { // 在所有预取钩子(preFetch hook) resolve 后， // 我们的 store 现在已经填充入渲染应用程序所需的状态。 // 当我们将状态附加到上下文，并且 `template` 选项用于 renderer 时， // 状态将自动序列化为 `window.__INITIAL_STATE__`，并注入 HTML。 context.state = store.state; resolve(app); }).catch(reject); }, reject); }); } [代码] 客户端托管全局状态 当服务端使用模板进行渲染时，[代码]context.state[代码]将作为[代码]window.__INITIAL_STATE__[代码]状态，自动嵌入到最终的[代码]HTML[代码] 中。而在客户端，在挂载到应用程序之前，[代码]store[代码]就应该获取到状态，最终我们的[代码]entry-client.js[代码]被改造为如下所示： [代码]import createApp from './app'; const { app, router, store } = createApp(); // 客户端把初始化的store替换为window.__INITIAL_STATE__ if (window.__INITIAL_STATE__) { store.replaceState(window.__INITIAL_STATE__); } if (router) { router.onReady(() => { app.$mount('#app') }); } else { app.$mount('#app'); } [代码] 常见问题的解决方案 至此，基本的代码改造也已经完成了，下面说的是一些常见问题的解决方案： 在服务端没有[代码]window[代码]、[代码]location[代码]对象： 对于旧项目迁移到[代码]SSR[代码]肯定会经历的问题，一般为在项目入口处或是[代码]created[代码]、[代码]beforeCreate[代码]生命周期使用了[代码]DOM[代码]操作，或是获取了[代码]location[代码]对象，通用的解决方案一般为判断执行环境，通过[代码]typeof window[代码]是否为[代码]'undefined'[代码]，如果遇到必须使用[代码]location[代码]对象的地方用于获取[代码]url[代码]中的相关参数，在[代码]ctx[代码]对象中也可以找到对应参数。 [代码]vue-router[代码]报错[代码]Uncaught TypeError: _Vue.extend is not _Vue function[代码]，没有找到[代码]_Vue[代码]实例的问题： 通过查看[代码]Vue-router[代码]源码发现没有手动调用[代码]Vue.use(Vue-Router);[代码]。没有调用[代码]Vue.use(Vue-Router);[代码]在浏览器端没有出现问题，但在服务端就会出现问题。对应的[代码]Vue-router[代码]源码所示： [代码]VueRouter.prototype.init = function init (app /* Vue component instance */) { var this$1 = this; process.env.NODE_ENV !== 'production' && assert( install.installed, "not installed. Make sure to call `Vue.use(VueRouter)` " + "before creating root instance." ); // ... } [代码] 服务端无法获取[代码]hash[代码]路由的参数 由于[代码]hash[代码]路由的参数，会导致[代码]vue-router[代码]不起效果，对于使用了[代码]vue-router[代码]的前后端同构应用，必须换为[代码]history[代码]路由。 接口处获取不到[代码]cookie[代码]的问题： 由于客户端每次请求都会对应地把[代码]cookie[代码]带给接口侧，而服务端[代码]Web Server Frame[代码]作为代理服务器，并不会每次维持[代码]cookie[代码]，所以需要我们手动把 [代码]cookie[代码]透传给接口侧，常用的解决方案是，将[代码]ctx[代码]挂载到全局状态中，当发起异步请求时，手动带上[代码]cookie[代码]，如下代码所示： [代码]// createStore.js // 在创建全局状态的函数`createStore`时，将`ctx`挂载到全局状态 export function createStore({ ctx }) { return new Vuex.Store({ state: { ...state, ctx, }, getters, actions, mutations, modules: { // ... }, plugins: debug ? [createLogger()] : [], }); } [代码] 当发起异步请求时，手动带上[代码]cookie[代码]，项目中使用的是[代码]Axios[代码]： [代码]// actions.js // ... const actions = { async getUserInfo({ commit, state }) { let requestParams = { params: { random: tool.createRandomString(8, true), }, headers: { 'X-Requested-With': 'XMLHttpRequest', }, }; // 手动带上cookie if (state.ctx.request.headers.cookie) { requestParams.headers.Cookie = state.ctx.request.headers.cookie; } // ... let userInfoRes = await Axios.get(`${requestUrlOrigin}${url.GET_USERINFO}`, requestParams); commit(globalTypes.SET_USERINFO, { userInfo: userInfoRes.data, }); } }; // ... [代码] 接口请求时报[代码]connect ECONNREFUSED 127.0.0.1:80[代码]的问题 原因是改造之前，使用客户端渲染时，使用了[代码]devServer.proxy[代码]代理配置来解决跨域问题，而服务端作为代理服务器对接口发起异步请求时，不会读取对应的[代码]webpack[代码]配置，对于服务端而言会对应请求当前域下的对应[代码]path[代码]下的接口。 解决方案为去除[代码]webpack[代码]的[代码]devServer.proxy[代码]配置，对于接口请求带上对应的[代码]origin[代码]即可： [代码]let requestUrlOrigin; if (state.ctx.URL.hostname === 'localhost' || state.ctx.URL.hostname === '127.0.0.1') { // 本地开发，转到localhost:9000 requestUrlOrigin = constParams.CONST_LOCAL_WEBSERVER_ORIGIN; } else { // 测试环境、正式环境、盒子 requestUrlOrigin = state.ctx.URL.origin; } let userInfoRes = await Axios.get(`${requestUrlOrigin}${url.GET_USERINFO}`, requestParams); [代码] 对于[代码]vue-router[代码]配置项有[代码]base[代码]参数时，初始化时匹配不到对应路由的问题 在官方示例中的[代码]entry-server.js[代码]： [代码]// entry-server.js import { createApp } from './app'; export default context => { // 因为有可能会是异步路由钩子函数或组件，所以我们将返回一个 Promise， // 以便服务器能够等待所有的内容在渲染前， // 就已经准备就绪。 return new Promise((resolve, reject) => { const { app, router } = createApp(); // 设置服务器端 router 的位置 router.push(context.url); // ... }); } [代码] 原因是设置服务器端[代码]router[代码]的位置时，[代码]context.url[代码]为访问页面的[代码]url[代码]，并带上了[代码]base[代码]，在[代码]router.push[代码]时应该去除[代码]base[代码]，如下所示： [代码]router.push(context.url.replace('/base', '')); [代码] 小结 本文为笔者通过对现有项目进行改造，给现有项目加上[代码]Vue[代码]服务端渲染的实践过程的总结。 首先阐述了什么是[代码]Vue[代码]服务端渲染，其目的、本质及原理，通过在服务端使用[代码]Vue[代码]的虚拟[代码]DOM[代码]，形成初始化的[代码]HTML[代码]字符串，即应用程序的“快照”。带来极大的性能优势，包括[代码]SEO[代码]优势和首屏渲染的极速体验。之后阐述了[代码]Vue[代码]服务端渲染的基本用法，即两个入口、两个[代码]webpack[代码]配置，分别作用于客户端和服务端，分别生成[代码]vue-ssr-client-manifest.json[代码]与[代码]vue-ssr-server-bundle.json[代码]作为打包结果。最后通过对现有项目的改造过程，包括对路由进行改造、数据预获取和状态初始化，并解释了在[代码]Vue[代码]服务端渲染项目改造过程中的常见问题，帮助我们进行现有项目往[代码]Vue[代码]服务端渲染的迁移。

适应场景： 小程序页面跳转redirect/navigate/其它方式 分析： 从用户触发跳转行为到下一个页面onload生命周期函数内时间差会有500ms左右，如果在页面跳转之后进行onload函数内才开始去加载页面数据，那么这500ms左右的时间就浪费了。 改进： 在页面触发跳转行为的处理函数里结合promise预先加载下个页面的数据，并将promise对象缓存，此时页面跳转和加载数据同时进行，到了目标页面再取出缓存的promise对象进行判断和取数据操作。 效果： 跳转页面加载速度提高了600ms。 示例： 代码结构 [图片] pageManager.js [代码]// 写在utils里的公用方法 const pageList = {}; module.exports = { putData:function(pageName, data){ pageList[pageName] = data; }, getData:function(pageName){ return pageList[pageName]; } } [代码] util.js [代码]const myPromise = fn => obj => { return new Promise((resolve, reject) => { obj.complete = obj.success = (res) => { resolve(res); } obj.fail = (err) => { reject(err); } fn(obj); }) } module.exports = { myPromise : myPromise } [代码] index.js [代码]// 跳转页面 const {myPromise} = require('../../utils/util'); const pageManager = require('../../utils/pageManager'); page({ data: { }, onLoad:function(){ }, gotoPageA:function(){ const PromisePageA = myPromise(wx.request)({ url : '' }).then((res)=>{ return res.data; }) pageManager.putData('pageA',promisePageA); wx.navigateTo({ url: 'pages/pageA/pageA' }) } }) [代码] pageA.js [代码]// 被跳转页面 const util = require('../../utils/util.js'); const pageManager = require('../../utils/pageManager'); const {myPromise} = require('../../utils/util'); Page({ data:{ logs:[] }, onLoad: function(){ const promisePageA = pageManager.getData('pageA'); if(promisePageA){ const resData = promisePageA.then( function(data){ }, function(){ console.log("err"); } ) } } }) [代码]

1.背景 如今信息流业务是各大互联网公司争先抢占的一个大面包，为了提高用户的后续消费，产品想出了各种各样的方法，例如在微视中，用户可以无限上拉出下一条视频；在知乎中，也可以无限上拉出下一条回答。这样的操作方式用户体验更好，后续消费也更多。最近几年的时间，微信小程序已经从一颗小小的萌芽成长为参天大树，形成了较大规模的生态，小程序也拥有了一个很大的流量入口。 2.demo体验 那如何才能在小程序中实现类原生APP效果的下一条无限刷体验？ 这篇文章详细记录了下一条无限刷效果的实现原理，以及细节和体验优化，并将相关代码抽象成一个微信小程序代码片段，有需要的同学可查看demo源码。 线上效果请用微信扫码体验： [图片] 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a 3.实现原理 出于性能和兼容性考虑，我们尽量采用小程序官方提供的原生组件来实现下一条无限刷效果。我们发现，可以将无限上拉下一篇的文章看作一个竖向滚动的轮播图，又由于每一篇文章的内容长度高于一屏幕高度，所以需要实现文章内部可滚动，以及文章之间可以上拉和下拉切换的功能。 在多次尝试后，我们最终采用了在[代码]<swiper>[代码]组件内部嵌套一个[代码]<scroll-view>[代码]组件的方式实现，利用[代码]<swiper>[代码]组件来实现文章之间上拉和下拉切换的功能，利用[代码]<scroll-view>[代码]来实现一篇文章内部可上下滚动的功能。 所以页面的dom结构如下所示： [代码]<swiper class='scroll-swiper' circular="{{false}}" vertical="{{true}}" bindchange="bindChange" skip-hidden-item-layout="{{true}}" duration="{{500}}" easing-function="easeInCubic" > <block wx:for="{{articleData}}"> <swiper-item> <scroll-view scroll-top="0" scroll-with-animation="{{false}}" scroll-y > content </scroll-view> </swiper-item> </block> </swiper> [代码] 4.性能优化 我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。例如减少代码包体积，使用分包，渲染性能优化等。下面主要讲一下渲染性能优化。 4.1 dom优化 由于页面需要无限上拉刷新，所以要在[代码]<swiper>[代码]组件中不断的增加[代码]<swiper-item>[代码]，这样必然会导致页面的dom节点成倍数的增加，最后非常卡顿。 为了优化页面的dom节点，我们利用[代码]<swiper>[代码]的[代码]current[代码]和[代码]<swiper-item>[代码]的[代码]index[代码]来做优化，控制是否渲染dom节点。首先，仅当[代码]index <= current + 1[代码]时渲染[代码]<swiper-item>[代码]，也就是页面中最多预先加载出下一条，而不是将接口返回的所有后续数据都渲染出来；其次，对于用户已经消费过的之前的[代码]<swiper-item>[代码]，不能直接销毁dom节点，否则会导致[代码]<swiper>[代码]的[代码]current[代码]值出现错乱，但是我们可以控制是否渲染[代码]<swiper-item>[代码]内部的子节点，我们设置了仅当[代码]current <= index + 1 && index -1 <= current[代码]时才会渲染[代码]<swiper-item>[代码]中的内容，也就是仅渲染当先文章，及上一篇和下一篇的文章内容，其他文章的dom节点都被销毁了。 这样，无论用户上拉刷新了多少次，页面中最多只会渲染3篇文章的内容，避免了因为上拉次数太多导致的页面卡顿。 4.2 分页时setData的优化 setData工作原理 [图片] 小程序的视图层目前使用[代码]WebView[代码]作为渲染载体，而逻辑层是由独立的 [代码]JavascriptCore[代码] 作为运行环境。在架构上，[代码]WebView[代码] 和 [代码]JavascriptCore[代码] 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 [代码]evaluateJavascript[代码] 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 [代码]JS[代码] 脚本，再通过执行 [代码]JS[代码] 脚本的形式传递到两边独立环境。 而 [代码]evaluateJavascript[代码] 的执行会受很多方面的影响，数据到达视图层并不是实时的。 每次 [代码]setData[代码] 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。 [代码]setData[代码] 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。 [代码]setData[代码] 是小程序开发中使用最频繁的接口，也是最容易引发性能问题的接口。 避免不当使用setData [代码]data[代码] 应仅包括与页面渲染相关的数据，其他数据可绑定在this上。使用 [代码]data[代码] 在方法间共享数据，会增加 setData 传输的数据量，。 使用 [代码]setData[代码] 传输大量数据，通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据，使用 [代码]setData[代码] 的特殊 [代码]key[代码] 实现局部更新。 避免不必要的 [代码]setData[代码]，避免短时间内频繁调用 [代码]setData[代码]，对连续的setData调用进行合并。不然会导致操作卡顿，交互延迟，阻塞通信，页面渲染延迟。 避免在后台页面进行 [代码]setData[代码]，这样会抢占前台页面的渲染资源。可将页面切入后台后的[代码]setData[代码]调用延迟到页面重新展示时执行。 优化示例 无限上拉刷新的数据会采用分页接口的形式，分多次请求回来。在使用分页接口拉取到下一刷的数据后，我们需要调用[代码]setData[代码]将数据写进[代码]data[代码]的[代码]articleData[代码]中，这个[代码]articleData[代码]是一个数组，里面存放着所有的文章数据，数据量十分庞大，如果直接[代码]setData[代码]会增加通讯耗时和页面更新开销，导致操作卡顿，交互延迟。 为了避免这个问题，我们将[代码]articleData[代码]改进为一个二维数组，每一次[代码]setData[代码]通过分页的 [代码]cachedCount[代码]标识来实现局部更新，具体代码如下： [代码]this.setData({ [`articleData[${cachedCount}]`]: [...data], cachedCount: cachedCount + 1, }) [代码] [代码]articleData[代码]的结构如下： [图片] 4.3 体验优化 解决了操作卡顿，交互延迟等问题，我们还需要对动画和交互的体验进行优化，以达到类原生APP效果的体验。 在文章间上拉切换时，我们使用了[代码]<swiper>[代码]组件自带的动画效果，并通过设置[代码]duration[代码]和[代码]easing-function[代码]来优化滚动细节和动画。 当用户阅读文章到底部时，会提示下一篇文章的标题等信息，而在页面上拉时，由于下一篇文章的内容已经加载出来了，这样在滑动过程中会出现两个重复的标题。为了避免这种情况出现，我们通过一个占满屏幕宽高的空白[代码]<view>[代码]来将下一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]hidden="{{index !== current && index !== current + 1}}"[代码]来隐藏这个空白[代码]<view>[代码]，并对这个空白[代码]<view>[代码]的高度变化增加动画，来实现下一篇文章从屏幕底部滚动到屏幕顶部的效果： [代码].fake-scroll { height: 100%; width: 100%; transition: height 0.3s cubic-bezier(0.167,0.167,0.4,1); } [代码] [图片] 而当用户想要上拉查看之前阅读过的文章时，我们需要给用户一个“下滑查看上一条”提示，所以也可以采用同上的方式，通过一个占满屏幕宽高的提示语[代码]<view>[代码]来将上一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]wx:if="{{index + 1 === current}}"[代码]来隐藏这个提示语[代码]<view>[代码]，并对这个提示语[代码]<view>[代码]的透明度变化增加动画，来实现下拉时提示“下滑查看上一条”的效果： [代码].fake-previous { height: 100%; width: 100%; opacity: 0; transition: opacity 1s ease-in; } .fake-previous.show-fake-previous { opacity: 1; } [代码] 至此，这个类原生APP效果的下一条无限刷体验的需求的所有要点和细节都已实现。 记录在此，欢迎交流和讨论。 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a

[图片] 微信宣布小程序将可以在PC端微信打开后，智库君就接到要求，需要兼容PC端小程序，一开始以为官方已经做了完美适配，不需要改什么，但当本人下载内测版开始测试的时候，才发现或许坑还挺多的~~~ 下面分享下本人“搬砖填坑”的全过程： （以下都是PC端小程序特有的问题，手机端正常） 先说下使用流程 [图片] 微信开发者工具菜单栏点击 设置->通用设置，在自动预览部分勾选“启动 PC 端自动预览”。 使用自动预览功能，点击 预览->自动预览->编译并预览，成功的话将在微信 PC 版上自动拉起小程序。 [图片] PC版打开后就横屏问题 [图片] [代码]{ "pages": [], "resizable":false, //在这里设置false，使得小程序默认手机尺寸 "pageOrientation":"portrait", //这里默认设置即可 ... } [代码] PC版微信默认打开小程序是ipad版，这样就会出现各种形变，布局错乱，这个可以在app.json进行配置，静止自动旋转，默认手机竖屏样子打开。 页面找不到问题 [图片] 这个问题本人也找了很久，一直很纳闷IDE工具和手机打开看都没什么问题，用PC打开小程序就出现页面找不到的情况，大致报错是： [代码]page[pages/XXX/XXX] not found.May be caused by :1. Forgot to add page route in app.json.2. Invoking Page() in async task. [代码] 一般这种情况以往是 app.json没配，或者页面里面缺少page(),但这次诡异的地方是只有“PC版小程序”报这个错！后来分析问题发现是：目前PC版小程序不能直接支持ES6，必须转换成ES5，同时由于一些语法转化不够完善，特别是ES7中的await 和 async 导致转化二次报错，这里就需要打开 “增强编译” 配置。 [图片] 打开有CSS报错 [图片] 因为目前PC版小程序估计内核的机制问题，还只支持低版本的选择器，如果你直接写小程序的标签，它无法识别，比如 [代码].popCont navigator{ //navigator 标签是小程序里的，PC端无法支持 width: 560rpx; height: 300rpx; } .popCont image{ //image 标签是小程序里的，PC端无法支持 width: 560rpx; height: 300rpx; } [代码] 但这些写法，其实在手机小程序和IDE工具里是完全正常的，PC版需要做兼容，改成class选择器。 布局结构混乱 如果遇到这种情况，会检查一下是否使用屏幕尺寸（rpx）来计算布局，PC 上屏幕尺寸比窗口尺寸大，应该使用窗口尺寸来计算。 小程序如何判断是 PC 平台？ 通过 getSystemInfo 官方接口（platform 是 windows） 通过 UA（PC UA 包含 MiniProgramEnv/Windows） 微信官方PC版小程序内测地址: https://dldir1.qq.com/weixin/Windows/WeChat2.7.0_beta.exe 最新官方IDE调试工具 https://developers.weixin.qq.com/miniprogram/dev/devtools/nightly.html 往期回顾： [打怪升级]小程序评论回复和发帖功能实战（二） [打怪升级]小程序评论回复和发贴组件实战（一） [填坑手册]小程序Canvas生成海报（一） [拆弹时刻]小程序Canvas生成海报（二） [填坑手册]小程序目录结构和component组件使用心得

目前对于Javascript的模块化编程主要就是通过以下几种方法，一种就是AMD（Asynchronous Module Definition），它的具体实现是RequireJS；一种是CMD（Common Module Definition），它的具体实现是SeaJS；一种是CommonJs；还有就是es6新出的import/export，而熟悉其中一个模块化编程实现，就比较好理解其他模块化编程的思想，所以我们就从一个简单的RequireJS和Vue结合的模块编程项目开始了解RequireJS中的模块化编程思想，当然，这种组合也方便学习搞懂RequireJS和Vue。 一、AMD的一些基本规范 require.js加载的模块，是采用AMD规范。也就是说，模块必须按照AMD的规定来写。更多RequireJS用法和AMD规范请查看RequireJS官网。 定义一个模块： [代码]//math.js define(function (){ var add = function(x,y){ return x+y; } return { add : add } }); [代码] 引入一个模块： [代码]// math.js require(['math'], function(math){ alert(math.add(1,1)); }) [代码] 二、项目文件结构： [代码]|--assets：存放公共的静态资源文件比如图片，公共的css，js等。 |--components：公共的vue组件。 |--lib：公共的依赖文件，比如vue，requireJS，vue router等。 |--modules：各个模块独立的相关文件。 |--index.html：主入口的html文件。 |--main.js：主入口的js文件 |--require.config.js：require的配置文件 |--router.js：总的vue router路由文件 [代码] [图片] 三、创建require.config.js配置环境依赖 在这个项目里我引入了vue，vue-router，element。其中需要注意的是requireJS中的test.js插件的使用，text.js是为了模块化的加载html文件，但是许多浏览器不允许file：//访问任何文件，所以最好从本地Web服务器提供应用程序，而不是使用本地file：// URL，否则会遇到跨域的问题。 [代码]var require = { // 基于调用这个js的html的路径是基础路径 paths: { // 第三方库 "vue": "lib/vue/vue", "vueRouter":"lib/vue/vue-router", "ELEMENT":"lib/elementUI/index" }, // 设置js依赖特性 shim:{ // 公共模块 'baseModule': { deps: [ 'css!assets/css/common.css', ], }, 'ELEMENT': { deps: ["css!lib/elementUI/index.css","css!lib/elementUI/reset.css","vue"], exports: "ELEMENT" }, }, // 包设置 packages: [ { // 组件包路径 name: 'components', location: 'components', //相对这个文件的路径 main: 'component' }, { name: 'lib', location: 'lib', main: 'lib' }, { // 模块包路径 name: 'modules', location: 'modules', main: 'modules' }, ], map: { '*' : { "css": "lib/require/css.min", // require用于引入css的插件 "text": 'lib/require/text/' // require用于引入文本的插件 } }, timeout : "20000" } [代码] 四、创建index.html。 创建主入口的index.html文件之后，引入require.config.js，require.js和一些公共的css文件，特别要注意引入主要的main.js。main.js里是vue实例的开始和路由的引入等，后续的其他模块或者其他页面都是使用vue的extend去扩展当前的这个vue实例的。 [代码]<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>首页</title> <link rel="stylesheet" href="assets/css/common.css"> </head> <body> <div id="app"> <router-view></router-view> </div> <script type="text/javascript" src="require.config.js"></script> <script type="text/javascript" data-main="main.js" src="lib/require/require.js"></script> </body> </html> [代码] 五、创建main.js，引入路由。 [代码]require{[ "vue", "ELEMENT", "router" ], function(Vue,ELEMENT,router){ Vuew.use(ELEMENT); var app = new Vue({ el: "#app", components:{ }, data: function(){ return { } }, created(){ }, mounted: function(){ }, methods:{ }, router: router, }); }}; [代码] 六、定义模块中的某个页面。 在该项目中要定义一个页面的话，主要有这几部分：1.该页面的js入口，也就该页面的入口，它会加载该页面所需要的html模板，css文件，相关的一些组件；2.模板html文件；3.该页面的样式文件。需要注意的是，我们的模板html文件是基于vue的，在这里一个页面就相当于一个组件，因此它的html模板文件就只能有一个父元素，多个父元素的话vue会报错的。 比如我定义的一个首页的页面： 主入口的js: 其中js里就是跟平常我们使用.vue文件中的js的写法都差不多的。 [代码]define([ "vue", "text!modules/home/views/home/index.html", "css!modules/home/views/home/index.css", ],function(Vue,template,css){ return Vue.extend({ template: template, data() { return { msg: 'aaa' } }, components: { }, }) }) [代码] 模板html文件 [代码]<div class="index"> 首页{{msg}} </div> [代码] 模板样式文件 [代码].index{ background-color: #0d78bc; .index-body{ background-color: #00b38a; } } [代码] 总结： 虽然现在requirejs不是那么热门，可是去了解它，这样能帮助我们更好的理解一些模块化的底层实现方法，可以让我们对目前一些主流的构建工具中的分模块功能的实现原理有一定的帮助，当然本实例只是为大家提供一种require+vue和vue的一些插件实现一个SPA项目的方法，要是有其中有不正确的地方，欢迎指出。

为什么使用自定义导航 对比默认导航栏，我们会更需要： 统一Android、IOS手机对于页面title的展示样式及位置 更丰富的导航栏定制效果，如添加home图标等 左上角返回事件的监听处理 统一实现双击返回顶部功能 自定义导航组件实现思路 自定义导航组件实现的核心是需要计算导航栏的真实高度 这里以官方文档->扩展能力中的Navigation组件为例分析实现思路。当使用"navigationStyle": "custom"时，默认导航被移除，页面的开始位置变成了屏幕顶部，这时我们需要实现的导航栏是在状态栏下面。 导航栏的真实高度=状态栏高度+导航栏内容。 [图片] 使用wx.getSystemInfo获取到statusBarHeight便是导航栏的高度，但是导航栏内容高度呢？ 有人可能觉得导航栏内容高度顾名思义就是导航栏内容高度啊，内容撑起还用管嘛！要，必须要！ 因为右上角胶囊按钮是原生加载的，我们的导航栏内容需要正好贴在胶囊的下方且垂直居中。 导航栏内容高度=（胶囊按钮的顶部距离 - 状态高度）*2 + 胶囊高度 [图片] 如何计算胶囊的数据呢？幸运的是我们有 wx.getMenuButtonBoundingClientRect() 获取胶囊按钮的布局位置信息，那么动态计算导航栏的内容高度就很方便啦。 好了，以上就是动态计算的核心思路，我们再来看官方Navigation组件高度是怎么实现的 [代码]page{--height:44px;--right:190rpx;} .weui-navigation-bar .android{--height:48px;--right:222rpx} .weui-navigation-bar__inner{ position:fixed;top:0;left:0;z-index:5001;display:flex;align-items:center; height:var(--height);padding-right:var(--right);width:calc(100% - var(--right)) } [代码] 导航栏内容的高度是通过- -height这个css变量提前声明好的，安卓机型会重新覆盖为新的css变量值，目前没发现有适配问题。 官方就是官方啊，具体尺寸都知道，那就不用一番计算周折啦，直接拿来主义即可。 导航的布局位置已经搞定啦，剩下就是写具体的内容，不同业务实现需求不同这里就不一一赘述了。 完善官方顶部导航组件 本着拿来主义，直接使用官方Navigation组件，但在实际业务开发中还是遇到不少需要自定义的需求，就比如： loadding样式没实现 标题内容超出没有出现省略号 和原生顶部的样式不兼容，导致单个页面引入时跳转有明显差异出现 没有双击返回顶部功能开关功能 引入页面需要获取导航栏的高度，来控制其他元素距离顶部的位置， 不能根据页面栈数据动态显示隐藏back按钮， 针对以上需求，我们对官方的组件进行二次完善开发，满足常规的自定义需求绰绰有余，直接引入开箱即用。 源码使用示例 https://github.com/YuniorZen/minicode-debug/tree/master/minicode02 [图片] 使用说明 [代码]/*自定义头部导航组件，基于官方组件Navigation开发。*/ <navigation-bar title="会员中心" bindgetBarInfo="getBarInfo"></navigation-bar> [代码] 组件属性列表 属性 类型 描述 bindgetBarInfo function 组件实例载入页面时触发此事件，首参为event对象，event.detail携带当前导航栏信息，如导航栏高度 event.detail.topBarHeight bindback function 点击back按钮触发此事件响应函数 backImage string back按钮的图标地址 homeImage string home按钮的图标地址 ext-class string 添加在组件内部结构的class，可用于修改组件内部的样式 title string 导航标题，如果不提供为空 background string 导航背景色，默认#ffffff color string 导航字体颜色 dbclickBackTop boolean 是否开启双击返回顶部功能，默认true border boolean 是否显示顶部导航下边框分割线，默认false loading boolean 是否显示标题左侧的loading，默认false show boolean 显示隐藏导航，隐藏的时候navigation的高度占位还在,默认true left boolean 左侧区域是否使用slot内容，默认false center boolean 中间区域是否使用slot内容，默认false Slot name 描述 left 左侧slot，在back按钮位置显示，当left属性为true的时候有效 center 标题slot，在标题位置显示，当center属性为true的时候有效 自定义顶部导航目前存在的坑 弹窗的背景蒙层无法覆盖原生胶囊按钮 页面下拉刷新的圆点会被自定义导航遮盖 如果要自定义顶部导航，以上问题避免不了，只能忍着接受。 目前还没遇到完美的解决方案，针对下拉刷新圆点被遮挡的问题微信官方还在需求开发中，如果你有好的想法欢迎留言反馈，一起学习交流。

最近老是有同学问我小程序ocr识别的问题，就趁机研究了下，实现了小程序识别身份证，银行卡，驾照，营业执照，图片文字的功能。今天来给大家讲讲详细的实现流程。 先画一张流程图出来 [图片] 第一次看到这个流程图，可能有点萌，什么云开发，云函数。。。。 不要着急，我们接下来会一步步带大家实现。 先看下我们的页面和效果图。 [图片] 功能其实很简单，就是我们点对应的按钮后，去拍照或者去相册选择对应的图片。然后把图片上传到云存储，会有一个对应的图片url，然后把这个图片url传递到云函数，然后云函数里使用小程序的开发ocr能力，来识别图片，返回对应的信息回来。如下图所示，我们识别银行卡（身份证什么的就不演示了，涉及到石头哥个人隐私） [图片] 接下来就是代码的实现了。 一，首先要创建一个云开发的小程序项目 这里我前面文章有讲解过，就不再细说了，不会的同学去翻看下我之前的文章。或者看下我录制的 讲解视频 这里有一点需要注意的给大家说下 [图片] 二，创建一个简单的小程序页面 1，index.wxml如下 [图片] 2，index.js完整代码如下 [代码]Page({ //身份证 shenfenzheng() { this.photo("shenfenzheng") }, //银行卡 yinhangka() { this.photo("yinhangka") }, //行驶证 xingshizheng() { this.photo("xingshizheng") }, //拍照或者从相册选择要识别的照片 photo(type) { let that = this wx.chooseImage({ count: 1, sizeType: ['original', 'compressed'], sourceType: ['album', 'camera'], success(res) { // tempFilePath可以作为img标签的src属性显示图片 let imgUrl = res.tempFilePaths[0]; that.uploadImg(type, imgUrl) } }) }, // 上传图片到云存储 uploadImg(type, imgUrl) { let that = this wx.cloud.uploadFile({ cloudPath: 'ocr/' + type + '.png', filePath: imgUrl, // 文件路径 success: res => { console.log("上传成功", res.fileID) that.getImgUrl(type, res.fileID) }, fail: err => { console.log("上传失败", err) } }) }, //获取云存储里的图片url getImgUrl(type, imgUrl) { let that = this wx.cloud.getTempFileURL({ fileList: [imgUrl], success: res => { let imgUrl = res.fileList[0].tempFileURL console.log("获取图片url成功", imgUrl) that.shibie(type, imgUrl) }, fail: err => { console.log("获取图片url失败", err) } }) }, //调用云函数，实现OCR识别 shibie(type, imgUrl) { wx.cloud.callFunction({ name: "ocr", data: { type: type, imgUrl: imgUrl }, success(res) { console.log("识别成功", res) }, fail(res) { console.log("识别失败", res) } }) } }) [代码] 上面代码注释讲解的很清楚了，再结合我们的流程图，相信你可以看明白。 [图片] 三，重头戏来了，识别的核心代码是下面这个云函数 [图片] 云函数的完整代码也给大家贴出来 [代码]// 云函数入口文件 const cloud = require('wx-server-sdk') cloud.init() // 云函数入口函数 exports.main = async(event, context) => { let { type, imgUrl } = event switch (type) { case 'shenfenzheng': { // 识别身份证 return shenfenzheng(imgUrl) } case 'yinhangka': { // 识别银行卡 return yinhangka(imgUrl) } case 'xingshizheng': { // 识别行驶证 return xingshizheng(imgUrl) } default: { return } } } //识别身份证 async function shenfenzheng(imgUrl) { try { const result = await cloud.openapi.ocr.idcard({ type: 'photo', imgUrl: imgUrl }) return result } catch (err) { console.log(err) return err } } //识别银行卡 async function yinhangka(imgUrl) { try { const result = await cloud.openapi.ocr.bankcard({ type: 'photo', imgUrl: imgUrl }) return result } catch (err) { console.log(err) return err } } //识别行驶证 async function xingshizheng(imgUrl) { try { const result = await cloud.openapi.ocr.vehicleLicense({ type: 'photo', imgUrl: imgUrl }) return result } catch (err) { console.log(err) return err } } [代码] 其实没什么特别的，就是用一个switch方法，根据用户传入的不同的type值，来实现不同的识别效果。 如用传入的type是‘ yinhangka’，我们就调用银行卡识别 [代码]try { const result = await cloud.openapi.ocr.bankcard({ type: 'photo', imgUrl: imgUrl }) return result } catch (err) { console.log(err) return err } [代码] 进而把识别的结果返回给小程序端，如下图 [图片] 到这里我们就完整的实现了，小程序识别身份证，银行卡，行驶证的功能。至于别的更多的ocr识别，可以去看小程序官方文档，结合着我的这篇文章，相信你也可以轻松实现更多的图片识别。 [图片] 源码其实在上面都已经贴给大家了，如果你觉得不完整，想要完整的源码可以在文章底部留言或者私信我。

onload-more.js的内容如下 /* * 分页加载数据 */ const onloadMore = Behavior({ // 组件加载 attached() { if (thisdata.autoOnload) { // 开启自动加载数据let pages = getCurrentPages()let page = pages[pages.length - ] this.onShow() if (thisdata.onShowRefresh) { // 每次onShow都刷新数据// 拦截当前页面的onShow事件let oldOnShow = page.onShow page.onShow = () => { if (this.isActive()) { this.onShow() } if (oldOnShow) { oldOnShow() } } } // 拦截当前页面的上拉触底事件let oldOnReachBottom = page.onReachBottom page.onReachBottom = () => { if (this.isActive()) { this.onReachBottom() } if (oldOnReachBottom) { oldOnReachBottom() } } if (thisdata.isPullDownRefresh) { // 拦截当前页面的下拉刷新事件//需要设置 "enablePullDownRefresh": true,let oldOnPullDownRefresh = page.onPullDownRefresh page.onPullDownRefresh = () => { if (this.isActive()) { this.onPullDownRefresh() } if (oldOnPullDownRefresh) { oldOnPullDownRefresh() } } } } }, // 组件移除 detached() { // 组件移除后不再加载数据this.setData({ isInit: false }) }, observers: { 'params': function () { // 参数变化时初始化列表this.initList() } }, data: { autoOnload: true, // 是否自动加载数据,自动加载数据通过拦截页面的事件和生命周期实现 onShowRefresh: true, // 是否每次进入页面都刷新数据，当autoOnload为true时可用 isPullDownRefresh: true, // 是否开启下拉刷新 api: '', // 请求接口地址 isLoading: false, // 是否加载中 isEnd: false, // 数据是否已加载完毕 list: [], // 加载到的数据列表 page: { pageNum: , // 当前第几页 pageSize: 10// 每页多少条 }, params: {}, // 请求额外参数 isInit: false// 列表数据是否已经初始化 }, methods: { isActive () { returnthis.data.isInit }, // 组件所在页面的onShow事件 onShow () { this.initList() }, // 组件所在页面的onReachBottom事件 onReachBottom () { // 加载更多if (!thisdata.isEnd && !thisdata.isLoading) {console.log('触底加载')this.loadData() } }, // 组件所在页面的onPullDownRefresh事件 onPullDownRefresh () { // 初始化数据this.initList() setTimeout(() => { wx.stopPullDownRefresh() }, 400) }, // 初始化列表 initList: function () { this.setData({ page: {pageNum: , pageSize: 10}, isEnd: false }, () => { this.loadData(true) }) }, // 加载数据成功 loadDataSuccess (isInit) { if (isInit) { // 列表数据初始化完成 } else { // 当前页数据加载完成 } }, // 加载数据 loadData: function (isInit) { if (thisdata.isEnd || !thisdata.api) { return } this.setData({ isLoading: true }) wx.$request({ // wx.$request是我在wx.request的基础上做了简单的封装 url: thisdata.api, data: Object.assign({}, thisdata.page, thisdata.params) }).then(res => { // res的格式 /* let res = { code: 200, data: { rows: [] } } */ this.loadDataSuccess(isInit) // 加载数据成功 let list = thisdata.list let obj = { isEnd: res.data.rows.length < thisdata.page.pageSize, // 判断是否结束 isLoading: false, page: Object.assign({}, thisdata.page, {pageNum: thisdata.page.pageNum + }) // pageNum + 1 } if (!isInit) { // 加载第二页及以上数据// 数据局部更新 res.data.rows.forEach(item, i) => { obj['list['+ (list.length + i) + ']'] = this.filterItem(item, list.length + i) }) } else { // 初始化列表 obj.isInit = true obj.list = res.data.rows.map(item, i) =>this.filterItem(item, i)) } this.setData(obj) }).catch(() => { this.setData({ isLoading: false }) }) }, // 过滤item，oldIndex为在list中的index filterItem (item, oldIndex) { return item } } }) module.exports = {onloadMore} 使用方法 注意：Behavior只能在组件中使用 information组件中使用 [图片] [图片] loading组件主要是数据加载中、数据为空、数据加载完成的提示 [图片] [图片] 效果 information组件就是列表部分 [图片] 最后 代码片段：https://developers.weixin.qq.com/s/vazUgPmi7kdQ 第一次写如果有人看我就更新多一些用法，还有如果大家有更好的建议欢迎一起交流啊

小程序日历组件 小程序日历组件，支持多种模式，简单易用好上手。 4种日历模式 3种日期选择方式 支持自定义节假日 支持自定义日期内容 懒加载保证渲染性能 支持农历 支持根据指定日期自动生成 支持跨无数据月份 [图片] [图片] [图片] [图片] [图片] 日历组件基础配置 wxml模板 [代码]<ui-calendar dataSource="{{config}}" /> [代码] 配置日历组件 [代码]Pager({ data: { source: { $$id: 'calendar', mode: 1, // 纵向日历 type: 'range', // 区域选择 tap: 'onTap', // page响应事件 total: 365, // 指定日历总天数 data: [], // 按给定日期计算total值，自动构建日历 rangeCount: 28, // 区选区间28天 rangeMode: 2, // 区选模式 rangeTip: ['入住', '离店'], // 区选提示 festival: true, // 开启节假日显示 alignMonth: false, // 月份对齐，swiper切换时 lunar: false, // 是否显示农历 date: [], // 指定日期显示的内容 value: ['2019-12-24', '2020-01-05'], // 默认值 toolbox: { monthHeader: true, // 是否显示月头 discontinue: false, // 自动构建时，是否省略无数据的月份 }, methods: { // 响应 tap事件 onTap(e, param, inst) { // param.date 选中的当前日期 // 当区选模式时 // param.range === 'start' 区选第一天 // param.range === 'end' 区选最后一天 } } } } }) [代码] github地址：https://github.com/webkixi/aotoo-xquery 小程序demo演示 [图片]