FDCon2017 中国前端开发者大会笔记
Contents
这篇文章根据嘉宾的文字发言汇总结合自己的理解而来。特别记录一下，以便更好的总结经验，吸收精华。
参加了第二届中国前端开发者大会，感觉各位嘉宾讲的都很高大上。下面根据金山文字的嘉宾发言汇总，整理一些自己认为有价值的部分，也算不虚此行。
尤雨溪–Vue 2017现状和展望
Vue从刚开始低调的负责视图view层的轻型mvvm框架，发展到现在和react平起平坐的渐进式框架，真的是一件了不起的工程。在台下感受着尤大大强大的气场，也学习到了很多东西。
关于渐进式
Vue的生态系统有提供完全的前端框架，并不是强迫你要用Vue一定要用所有的全家桶。你可以只用Vue本身，不需要一下子把所有东西都用上。
渐进式的好处，我个人理解是可以让开发者有一个良好的学习和使用体验。与angular和react相比，用了angular需要学习一整个angular生态的各种概念，ts，依赖注入等等规则，以及使用angular的路由，服务等全套规则；用了react需要自己去react丰富的而琐碎的社区中，自己寻找各种需要的库来完成整个项目的架构，有点像玩乐高积木，目前的react全家桶，只是社区中公认的一种实现方案，究竟是不是最佳实践也未可知；而Vue既不需要去接受一整套既定规则，也不需要像摸着石头过河一样去寻找最佳实践。
关于类型检查
引入了Flow类型检查，提高代码健壮性。
之前还在某个小密圈中看到了flow这个类型检查库，尤大大在现场答疑中也说到，在工程项目中用ts也许是更好的选择。但是当你不想用ts，又想加入类型检查，我觉得可以试试flow。
- 模版渲染机制的优化
Vue2.0有一个模板编译过程，两种编译模式，一种是运行时，一种是构建时，你直接把模板写在页面里面，Vue在页面加载之后，把模板编译成渲染函数。构建时渲染是打包发布的同时把原文件的模板处理运行时就不需要再编译一遍了。
bundlerenderer的概念
解决的问题：解决同构代码在服务端的构建和部署。
优点：
避免跨请求状况污染；除了入口文件和构建配置外，业务代码完全同构；服务端包和服务端代码解耦，便于部署，甚至可以热部署。
ScopedSlots的应用
传递一个可复用的模板片断给子组件。组件内部可以把传进来的组件内容，嵌入到组件自身里面，内容再组构的机制。可复用的模板片断可以获得子组件传回来的数据。
可以用这个技术在Vue中将http请求抽象，直接在模版层根据请求状态控制渲染，而不用关心具体的请求部分。个人理解这有点react中组件嵌套的概念。
- 带命名空间的module
可以包含自己的state，actions，mutations和getters，就像一个小的store。通过它们可以轻松的对业务逻辑进行分块封装，最后只需要在Root store入口处组合。甚至可以通过动态模块注册来配合代码分割/懒加载
- 改进Vue devtoos，支持weex查看状态快照
- 配合webpack完美支持路由级别的代码懒加载
- css代码分割，避免服务端渲染，js内嵌样式使首屏无样式的问题，也可以确保CSS跟随业务代码被分割出去
- 内置了Chrome timeline性能追踪支持，完善异常机制与报错信息
- 服务端渲染进一步改进
通过分析Webpack服务端和客户端的构建信息，自动推导需要在客户端与加载的文件，生成最优的
<script>和<link rel=“preload/prefetch”>链接;
自动选用不包含CSS字符串的异步JS文件，避免Critical CSS被两次下载。你在JavaScript有一个字符串是CSS，才指出的HTML里面也有字符船，等于字符串被重复了两次，我们会把每次割出去的代码包打两份，一份有CSS，一份没有CSS，避免首屏双重加载CSS的问题。
可以看出，Vue是一步步变得更强大，开发和使用体验都越来越好。希望下一个项目可以尝试一发。
魏晓军–CRN-WEB（Ctrip React Native Framework For Web）
之前在携程的技术分享会上，接触了CRN的一些相关知识，这次听到魏晓军老师的分享，也是有一丝亲切感。
CRN是携程在React Native上封装扩展了一层，解决了RN的一些坑，能够用同一套代码运行在安卓和ios上。
CRN-WEB则是在浏览器上跑React Native的代码。这样，浏览器，安卓，ios，三端同一套代码。很完美。
- CRN-WEB特点
- 基于ReactJS，兼容RN和CRN组件及接口的H5框架。可以快速生成已有或者即将开发的CRN项目的H5版本。
- 支持项目两种类型项目RN和CRN。你只要有RN代码，运行CRN-WEB的命令，立马可以转出来可以在Web上跑了。
- 开发体验友好，支持元素审查、源码改动动态刷新，运行时debug，远程真机调试。支持浏览器、微信等多平台。
- CRN-WEB的实现
- 适配了RN和CRN的API包括第三方的扩展，同时是基于ReactJS做的web前端框架。
- 主要基于ReactNative自身的东西，CRN的自身的东西，第三方的扩展，三个部分做的。
- 开发环境完全基于nodejs，快速搭建开发环境。使用简单、功能强大，支持源码调试。源码修改，自动热更新。
- 借鉴小程序的思路，开发CRN-WEB的IDE，方便开发。
- CRN-WEB的现状和发展
- 最大的痛点就是性能还有兼容性
- 和去哪儿团队合作开发YRN-WEB，两个团队会做一些切磋的东西，放在YRN-WEB里面，同一套底层，每家的业务代码加底层，可以运行到各家的APP里面去
渚薰–H5互动的正确打开方式
作为本次大会唯一一个和js关系不是那么密切，关于“交互”的分享，渚薰老师的演讲犹如一道餐后果蔬，营养丰富且清新健康。
首先介绍了互动的概念，已手淘为例，交互包括引流、氛围、橱窗、抽奖、视频、游戏、提醒，乃至VR/AR等等，并不只于点击。
总结下来，可以分为被动的获取和主动的寻求反馈。
然后介绍了互动的实现，也就是动效的原理–动画其实是动效+时间的完美配合。
其中，遇到了兼容性和性能优化两大问题。
兼容性问题，简单粗暴的满足95%的用户体验，剩下的用户默默砍掉。
性能优化问题，又有下面几点：
- CPU运算
js不擅长浮点运算，而动效的实现往往是差值的浮点运算。所以依次检查每个函数，重点优化最耗性能的那个 - GPU方面
虽然前端没办法访问GPU，js不能使用GPU运算，但是可以通过transform: translateZ()或者transform: translate3d()来开启硬件的GPU加速，帮助你渲染的流程从CPU挪到GPU，会减少CPU的压力。 - 图片栅格化
把你的一张原始图片变成像素点，这个时候如果像素很大，但是放到手机屏幕上，要缩小成你当时显示的区域的像素点的颜色值，这个时候很耗性能的，甚至在安卓里面，图片栅格化远远弱于IOS的，这个必须要注意的一点，你图片尽量不要大于你要显示的实际的像素大小。
- 避免过度绘制
手机屏幕呈现的部分对它渲染就可以了，不在区域内部的渲染都丢弃掉。不要直接的显示出来，这样子会提高你的整个渲染的效率。
- 关于降级
降级可以分为内容降级和版本降级。内容降级就是让动画元素、动画内容、例子效果少一点，保证主要内容的呈现；版本降级主要是关于3D版本和2D版本两套方案。
随后提到了和Native的亲密接触。在Native页面上面覆盖一个H5的View以实现动画效果，让动画和原生页面紧密结合在一起。
之后推荐了一套高效调整动画参数的工具。
Airbnb的，可以Adobe的动画导出JSON，通过Airbnb的软件运行，但是有一个问题，JSON要对它进行编辑很困难，我们通过它对DSL的转化，赋予它二次开发的能力，可以对JSON进行微调，把JSON数据整合起来运用到业务当中去。
最后说到了WebGL，这个Web3D技术可以针对GPU编程。可以先从最简单的Three.js学起。之后
推荐stack.gl的网站，帮助大家更系统的理解WebGL怎么编程的网站，里面有APM包，可以让你通过按需加载的方式获得一些能力让你在WebGL的道路上走的比较自然系统一点。
还有一些上层的框架，比如说Unity，微软的babylonJS都可以帮助你解决问题。
张强–Redux的打开方式
张强老师的演讲很棒，条理很清晰，无论是演讲稿还是slide，都是精心准备过的。
因为是关于Redux的，所以先从状态管理的角度，讲了前端的发展史。引出了遇到的问题，从而后面深入问题的解决方案。这个思路是很对我的胃口的。
前端的本质是做用户和数据的双向交互。最开始的前端架构，简单就是美。然而这种用户体验非常不好。
具体数据怎么处理我们前端不管，都是后端的事情，我们一般以URL区分不同的请求，一个请求发出去SERVER处理HTML直出。最完美的状况管理是浏览器前进后退的操作。
当时Web非常可靠，不容易出错，出错也好定位。学习成本低，浏览器搞定了大部分事情，开发者只需要关心UI渲染就可以了。
后来，AJAX的出现，改变了这一状态，也引来了一系列的复杂问题。
以前只有单一数据源，现在多了很多本地临时数据，以前只通过URL进行数据变更，现在多了AJAX的数据请求，和UI输入对本地数据进行修改。以前是统一的UI渲染方式，现在是HTML直出加上本地全局（局部）DOM渲染。而且浏览器的前进后退失效，状态都由自己管理。
我们进入AJAX发现应用中有多个数据源，维护多个数据源的一致性非常困难，多数据源有关联，导致应用中多处代码操作同一数据，预测一个操作带来的数据变更愈发困难。对于整个应用内的代码都能随便修改，用户说我这边颜色不对的时候，你就瞎了，你要看到底谁改了你的DOM，状态管理根本无从谈起。bug越修越多，我们还要加班重构代码。
React的出现，使事情发生了转机。但是独立的React架构，虽然在ui渲染方面，隔离了真实DOM，避免了DOM操作，但是每个组件都有自己的state，导致了多个数据源，数据的变更情况，React也没有约束。
结合了Redux后，React+Redux架构也只是有一个数据源：Redux的全局State。统一的数据变更是action出发。统一的UI渲染：react，状态管理：“时间旅行”。
但是，Redux也有其自身的问题：
- 把大象关冰箱一共三步，用Redux解决这个问题需要定义三个actionType，起三个不同的名字我们要实现三个actionCreator，最后实现三个reducer，感觉搞复杂了。
- Redux处理异步是很有问题的，它没有明确规定异步放在哪步。有的是放在View中，有的放在actionCreator里，有的利用中间件实现，有的反模式的放在了reducer中。
- 关于Redux模块化的问题，官方没有成熟的解决方案。
- actionType的重名问题，还是靠约定和代码规范。
- 模块动态加载的问题，势必会引入一个新的Reducer，就破坏了Redux关于reducer必须是纯函数的特性，时间旅行如何保证。
(未完待续。。)
Author: Wang He
Origin: http://wanghewanghe.github.io
Link: http://wanghewanghe.github.io/2017/04/09/FDCon2017-中国前端开发者大会笔记/
本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可