FEDay 参会小记

活动地址：http://fequan.com/2016/

注意：英文不好，小记也带有自己理解，部分内容可能包含严重的个人想法，不会按原话翻译，随机写得也乱，建议等几天找录播或 PPT 得到源文理解。

使用React、Redux和Node.js构建通用应用

作者网站是：http://www.stepanp.com/

先简单说个同构（通用）应用的概念：前端服务器端功能双向映射

过去，rails 中 路由、校验、视图都在 rails 中完成，js 只是用于做一些动画

现在，用 backbone 来构建单页不刷新页面，javascript 负责了路由、校验、视图等功能，成为了主角（目录结构仿照 rails）

介绍了 todomvc 看看同一种 todo 功能，用不同的类库来实现会是怎么写的

模板可以在 rails 中写，也可以在 javascript 中写，但很快就会失控，你如何判断这个功能模板应该在哪端写，类似功能的模板你怎么复用？

如果前后端都是 JS 的话，是不是就解决了这个问题？前后端共享路由、验证、视图逻辑

那么问题又来了，后端并没有 DOM，怎么用前端的写法来呈现 DOM 结构？

写一个虚拟 DOM ！前后端代码共享，React 应运而生。

优点：

• 共享代码（代码习惯一致，我们不再需要在前后端切换语言）

• 提升性能（计算逻辑放在后端执行，做到直出效果）

• 利于 SEO（后端吐出静态 HTML，必然带来了 SEO 效果）

那么，我们用什么技术栈来做这些事情呢？

• React（视图模板共享）

• Webpack + babel + family（构建工具）

• ReactRouter （路由）

• Redux（存储）

React 有了虚拟 DOM ，所以我们可以在服务器端很舒服地写 DOM 组件逻辑
接下来介绍 react 基础语法，几段代码示例，略。
需要注意的是，服务器端可以写虚拟 DOM 的逻辑，但事件绑定是需要到了浏览器端才能真正绑定的，可以理解为服务器端只为我们生成了模板，到了浏览器服端后不需要重新计算虚拟 DOM 的结构，用服务器端算好的 DOM 结构直接渲染，并直接添加事件绑定后即可。

构建工具用 webpack打包 + babel 转换 ES6/7 自然是目前最好的选择啦。

路由用 ReactRouter，声明式路由
浏览器端使用 ReactRouter 的browser history 功能，服务器端则使用 match 功能（考虑浏览器端禁用 JS 后，页面还能否渲染出来）。

存储用 redux，一个请求到来创建一个组件的同时，创建一个 store（即时创建，方便销毁避免内存泄露）

把旧数据缓存到 window.__DATA__，初始化时考虑使用缓存数据，感觉这个做法比较传统，初始化组件时在数据返回前先使用这份旧数据

拉取数据，单页应用必然是使用 ajax 异步去拉数据，这里讲师推荐了 isomorphic-fetch 模块来做 ajax 请求，讲师说这是同构应用中拉取数据的关键，我没明白什么意思，回头翻 PPT。。。

最后作者展望了下 JS 的未来，大一统不同的终端（iOS/Android等），希望能用 JS 来做不同端上视图、验证、路由等功能。呼吁我们去做这种事情，但我觉得不大可能。。。

微信Web APP开发最佳实践

介绍 JS-SDK，说的东西在微信开发文档中都有写，我就懒得打了，略。

手机机型统计图，作者贴了张微信安卓客户端机型前十的分布图，基本都是低端机，那叫一个惨，这个等 PPT 出来直接看吧。

介绍 X5，优点的为的是抹平不同 Android 版本不同 Webview 的坑，缺点是带来自己的 X5 坑（有点多）。

这里我体会比较深了，微信缓存清理比较蛋疼，客户端做的强缓存，对于普通用户来讲节省流量，对于我们开发来讲就繁琐了，微信设置中清缓存不一定有效。可以考虑 URL 中加时间戳的办法（记得 HTML 也要加，否则都不去拉 HTML 了）

黑科技：//triggerWebViewCacheCleanup 来清缓存！

布局方面，flex 只是部分支持，建议用 autoprefixer 等工具来补，只支持类似 -webkit-box 这种老写法，只能怪 X5 用的 webkit 内核版本太老了。

动画效果，伪元素不能使用动画效果，这个我也深有体会，建议用实体标签来模拟。

视频播放，controlrs 是不能隐藏的（除非你有白名单），ontimeupdate 事件可以触发，但 currentTime 是不准确的，autoplay 是不能使用的，这个是 iOS 普遍的问题，不经用户交互是无法自动播放媒体的，那监听 WXJSBridgeReady 事件再播放就好了（用户有交互）。

cookie 和 localStorage 失效的问题，听到后我都惊呆了。。。原因不明。这是不可靠的存储，不要太过于依赖。建议是 cookie 和 localStorage 都存一份。

UIWebView 有个 bug: 手势右滑和点返回按钮关闭 Webview 是行为不一致的，建议用 hash 来做历史记录管理。

介绍 WeUI, 微信风格的 UI，与客户端体验一致，这个自己去微信 github 上看 demo 吧，略。

WeUI 有 jquery/react/vue 版本，这点很赞。

微信调试一件套，网页授权、JS-SDK 模拟、集成 Chrome DevTools、代理、weinre 远程调试。这些在微信开发者中心有介绍，略。

X5 升级，改用了 Blink 内核，到现在 3 月 19 号未知，灰了大约 70%，计划到月底全量。

X5-Blink 有哪些新特性呢？

• Chrome inspect

• 标准的缓存策略

• 完整支持 flex

• canvas 支持 CSS 设置背景色了

• filter: blur 模糊可以用了

• 优化了动画卡顿问题

• 伪元素支持动画了

• 尼玛，PPT 太快，我刚肚子饿了还几点没记录到，别打我

升级后，很多坑自动没了，但我觉得肯定也会带来更多坑。XXX 年微信开发经验的人，终于又成为了零年开发经验的人，重新走上了踩坑之路。

React tips

Container Component

父子组件之间的数据传递、渲染、错误捕获，接入外部的 Store

先来看看 UI Component 需要什么

• 有数据/状态（data/state）

• UI 逻辑

• 可重用

• 需要测试

React 组件在 ComponentDidMount 时发起 ajax 数据，设置 setState 后，更新组件数据，重新渲染。

错误捕获的做法是，将 error 传进 state 中 this.setState({error: null}); 判断有 error 显示 Error 组件
处理 loading 的做法也是，将 loading 传进去 this.setState({isLoaded: false}); 判断有 isLoaded 显示菊花

对于 UI Component 来说，它不在需要关心数据哪里来的，只关心将 Container Component 传递下来的数据，进行渲染（无状态）。

我对讲师将的 Container Component 的理解是：Container Component 专门负责管理数据，然后将数据传递给子组件，也就是 UI Component（单向数据流）

多个组件需要复用统一份数据，所以我们需要有一个地方来存储通用数据，这就是 Store.

通过拿到一个 action ,改变了一个 store, 再将数据传递回去，这是一个简单的函数行为，而 flux 的实现就过于冗余，所以有了 redux。

Flux ReduceStore

其实就是监听到一个 action 将传过来的 state 进行合并，然后把新的 state 传递回去。

Functional *

强调无状态的组件（stateless component），一个组件就是一个函数，接受输入，将渲染结果输出。
如果一个父组件里面要产生很多子组件，那你就该将这个组件抽离出来，变成一个函数，给父组件使用。
这里讲师拿 underscore 的 _render 做反例，问题在于 render 嵌套太深，不好调试。
而无状态组件，只关注输入，保证输出。

所以建议是，组件嵌套不要太深，保证同时只有一个组件，接收一个输入，具有一份输出。（好绕）

这里讲的比较抽象，需要看了 PPT demo 代码才好理解，略（别打我）。

Decorator/HOC 高内聚组件

使用装饰器，不改变原有组件的前提下，加一下修饰包装后，返回一个新的组件（被赋予了额外的组件或行为）
好处就是，UI 层可以专心做渲染的事情，通过添加额外的装饰器，来产生不同功能的定制化组件，那么这个 UI 层组件，就做到了可重用。

map/filter/reduce

很多数组操作用 forEach 都可以完成，下面三个也都是数组具备的的方法，只是一些小技巧而已。
用 map 替代 forEach, 简化数据
用 filter 替代 forEach, 筛选数据
用 reduce 快速产生一个新对象

todos.reduce((todos, todo) => {
     todos[todo.id] = todo;
     return todos;
}, {})

这几点技巧，加上 ES6 的箭头函数来用，很多时候一行代码就能处理完，能让我们的代码更加简洁、可读。

讲师最后推荐了一个链接给大家看看：GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft's Reactive Extensions Library for Javascript.GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft's Reactive Extensions Library for Javascript.

这个讲题给我最大的体会就是，去深入思考如何真正得做可重用的组件化，同时让这份代码更加可读。

下一代Web技术运用

这个主题没听全，期待其他同学补充，略。

一个前端的自我修养

开场拿出 react/angular/week 调侃：你不会敢说你会前端？
前端在于难学，而是大家不知道怎么学。如何成为像 hax 一样的前端？

20% 知识：JS、DOM、Device API、CSS、DOM、HTML、HTTP、jQuery、React ...
80% 能力：编程能力、架构能力、工程能力

编程能力：解决问题的能力（基础）
架构能力：一定规模后带来架构问题
工程问题：关于人的问题，怎么让一个团队里的人怎么协作好

怎么提升知识与能力？

知识的学习

你写代码的初心是什么，你期望把程序写过来的感觉是什么？

建立并弄清楚自己的知识体系。

为了区分好 id 和 name 的区别，winter 借了十本书去查阅这个问题。

举例怎么建立自己的知识体系。

• 寻找线索

  • 比如学 JS, 控制台输入 for (var k in window) 看看有哪些属性，你了解这些东西么，查阅书籍能找到么？

  • 比如学 python，你了解全局有哪些东西么？

  • 看附录

  • 查源码

  • 反射

• 建立联系

  • childNodes/parentNode nextSibling/previousSibling 等有哪些关联，你理解么？顾名思义，举一反三，串起来学习。

  • 美感

  • 完备性（比如 jQuery 有 append 就有 prepend）

  • 操作同组数据（setTimeout/setInterval/clearTimeout/clearInterval）

• 归类

  • 画思维导图，例如你知道 zepto 有哪些 API 可以用么，能分类整理完整为一棵树么？

    • ajax

    • collection

    • dom

    • util

  • 见到前端争议的时候，你如何追本溯源找到知识？比如你知道闭包的解释，谁说的对么？

    • 查 wiki 看历史，谁定义了闭包这个概念：P J Landin

    • 查 Google 论文, P J 在一个期刊上发了篇文章，看看原文怎么定义闭包的

    • 闭包两部分：

      • 环境部分 environment

      • 控制（表达式）部分 control part

    • 通过辩证地最本溯源得到正确的判断，不断获得自信和社区声誉，这对于新人来说非常重要（摆脱新手 拍死前浪）

  • 追本溯源

    • 论文

    • 邮件列表

    • 代码提交记录（commits/issues）

• 挑战

  • 推翻旧知识，建立新知识，这是一个循环的过程，不断完善知识体系

能力的培养

能力培养没有捷径，但有投入的技巧。

推荐一本教材：《C++程序设计语言》（为什么是教材不叫书？因为没有习题）

推荐一本书：《黑客与画家》

习题很重要。习题很重要。习题很重要。

靠自然的提升不太可能，需要刻意的大量的训练。

• 主动性

  • 被动的 996 不会有成长

  • 每天主动再加几个小时学习才会有帮助

• 习惯养成

  • 保持在学习区、痛苦区工作（摆脱舒适区）

• 系统训练

  • 一万个小时理论太难，那从二十个小时开始呢？

HTTP/2时代的Web性能

作者是 @foobartel (新浪微博和推特) http://foobartel.com/

开场白：Nobody likes to wait.（含义：我们等待了 HTTP/2 太多年。）

开一个网站只需要 2-3 秒，用户就会觉得快。超过 4 秒没打开，50% 的用户就会选择离开，超过 8-10 秒，用户就会离开。

所以在 2-3 秒内打开页面，用户基本就不会抱怨。

不要以为很多用户都在用 wifi 打开网页速度很快，我们要考虑 3G/GPRS 甚至是离线的用户网络，所以更快才是更好。

现有的性能优化技巧：文件合并、精灵图片、内联图片、域名共享

有哪些地方可以优化？

渲染树的过程，DOM 布局与绘制（重绘）：

1. 等待 DOM 和 CSSDOM 构建渲染树

2. 渲染树节点

3. 计算布局、定位和尺寸

4. 绘制

渲染 CSS/JS/HTML，避免或减少各种阻塞问题

每个请求都带有开销，请求顺序优化。

最佳渲染路径：让内容更快的出现在页面上（减少白屏时间）

迎接 HTTP/2

HTTP/0.9
HTTP/1.0 1996
HTTP/1.1 1999

带宽的线性提高并没有带来页面加载速度的线性提高，这是协议带来的问题（连接数有限，RTT 请求时间固定开销）

RTT 相比带宽，对性能的影响更大。

SPDY/HTTP/2

1. 都支持多路复用

2. 都支持头部压缩

3. 都支持服务器端推送

4. HTTP2 支持优先级请求

5. HTTP2 向后兼容 HTTP/1.1

HTTP/1.1 中很多的优化技巧已经成为反模式。

HTTP/1.1 中我们为了减少体积和请求数，会做很多的合并。
HTTP/2 中同一个域名只会使用同一个 TCP 连接多路复用（不需要资源合并、资源内嵌）

1. 不需要 CDN combo 合并了

2. 不需要 JS/CSS 内嵌了

3. 不需要使用雪碧图了

4. HTTP/1.1 下很多优化技巧我们都可以抛弃，因为请求已经很廉价

HTTP/1.1 中我们为了打破浏览器并发请求次数的显示，将多个资源分布在不同的域名下。
HTTP/2 中，请求廉价，同域复用连接（理论上是无限的），所以我们要做域名收归。减少 DNS 解析反而成为了正确）

HTTP/2 中减少资源请求，域名分发不再必要，但HTTP/1.1 其他已有的优化技巧，还是需要继续使用，如 DNS 查找、减少重定向、使用 CDN、重用 CDN、开启压缩、开启缓存等。所幸的是，HTTP/2 是向后兼容的。

如何开启 HTTP/2

1. 开启 SSL/TLS

2. 服务器开启 支持，如 apache 的 mod_http2 模块

3. 检查客户端支持，caniuse.com 查兼容程度