2016年12月17号，博主去参加了d2，想写点记录。但是动手写的时候，发现其实没啥好写的。还是直接看知乎很多人的回答吧！参加第11届D2前端技术论坛，你有什么收获, 还是写点简单吧，要不然就没啥记录了。

行程

9点20左右到会场
做个公交一路上堵死了（o(╯□╰)o），到了会场就输入手机进行签到。签字墙上已经签的全是字了，还是来的太晚了。
9点30左右到会场门口
被今年的阿里吓住了，几乎整个会场外围都是阿里的。有送杯子的g2，有送照片的XUX，还有送’钱’的teambition。还有有意思的VR，博主还体验了一把。飞猪写了个‘贪吃蛇’游戏，太难玩了，说是用weex写的（o(╯□╰)o)。
9点50左右-weex场
因为现在博主所在公司，有用到与weex有关的QAP平台，所以博主想在weex场，听听有没有所帮助的。
由于之前迟到了，并没有听到完整的，只听了一小部分。总体感觉weex在底层做了很多的优化，但是对于博主或者对于开发者而言，并不需要太关注怎么优化的，更多的是要关注怎么在实际的项目的中怎么完美开发的，或者怎么避开现有的‘坑’，因为现在weex还在不断补全UI组件，但是实际项目中，需求是很多的，要做有特点、有个性的产品，现有的组件是满足不了的，扩展组件还需要原生支持，所以还是处在观望中。
10点30-前端服务化场
听上去，感觉像是产品发布会，做了很多东西，便于提高前端的开发效率，通向零成本。博主觉得这个东西适合一些固定的场景，比如运营广告页啥的。博主公司也有广告系统，便于投固定的广告、运营页。
11.30-磨刀石
简单听了前半下，就是解决无线真机调试问题。这个也就只有大厂能做了。呵呵~
12点
和妹子同事，@i蒹葭从风-峰哥，和@一丝姐姐吃饭。出乎意料的是一丝姐姐带着2个妹子一起来吃饭。♪(＾∀＾●)ﾉ
14点50左右-17点半
下午依次稍微听了Node.js在YunOS中的最佳实践、NW.js、ClojureScript，都是很蒙圈的，跟实际的项目需求并不是很多，更多是开拓了眼界。
回家
来张合照
夜场
博主回来还看来夜场的直播，@winter邀请大牛解答一些问题了。大牛都是站在很高的一个高度来看问题啦，对于博主而言，心里默默想: 恩，说的不错，对对对。但是还是自己一点点努力，脚踏实地。↖(^ω^)↗

总结

这次跟2016 css大会时间上冲突了，从知乎上看参加2016年12月17日广州第三届 CSS Conf 大会是个什么样的体验？，有很多写干货的，期待后面视频再学习下。

干货

其实在d2前一天，@徐飞大大，来我司给我们分享他的数据流的干货。这里结合博主的一些想法，记录下来。

过程

徐飞大大是基于teambition实际业务出发的，这也是他之前入职teambition的原因。teambition的任务管理产品，涉及了很多元数据的组合。博主简单可以举例为个人信息、任务信息、任务参与人员信息。一个任务可以多个人员参与，一个人员也可以参与多个任务。这是日常中最常用的操作了。

从这实际项目中，徐飞大大提出以下几点

同步和异步
同步和异步代码写法是不一致的，经常很多人会在处理回调的时候变的难受。怎么将同步和异步代码保持一致呢？
数据更新和拉取
一个用户更新了用户信息，怎么将用户信息发送给整个应用，同时要保证其他用户在使用的过程中，用户的信息也要保持最新的。这里面涉及到我们经常遇到的问题，就是数据的更新，一般情况下，博主会自己去触发请求，然后再更新视图。置于在推送信息，也就是保证共享信息的用户看到最新的数据，需要后端进行推送数据，而博主这边场景不多，一般前端轮训就能够满足。这2种数据方式的写法是不一样的，怎么保持一致呢？
数据组合
这里徐飞大大说了一个数据管道的一个概念，按照博主的理解，一个要展示的数据，进过好几层的组合加工，由最开始的纯粹数据一道一道的组合，最终组合成想要的数据。
如图所示的管道组合
由于博主的产品也会存在数据组合的情况，一般情况下，博主会自己进行组合数据，数据更新也会‘暴力’的全部更新，这样子实施简单。但是teambition里面的数据更新频繁，而且涉及到很多其它数据。怎么做才能更好的解决呢？
徐飞大大采用RxJs的数据表达式，比如D = A + B + C，RxJs会取ABC的最新数据，这就方便了上层调用数据。其实导致这个原因是由于后端没有去做接口合并，有能力可以增加个node层，用来做接口合并，这样ABC的数据前端只要一个接口就完事了。
数据规则
一个表格排序筛选，这个是一个正常的业务场景。但是在新的数据来了之后，该怎么做？徐飞大大提到了RxJS懒执行，用于解决此场景。其实在博主看来这个数据规则也是要看产品层次怎么做了，有时是要保持原有的规则，有时是重新重置参数回到最开始的规则。

MVVM

徐飞大大说明了MVVM的实际场景，M(数据源)->VM(视图控制)->V(展示)。这里就能很好的分析出M，其实还可以分为上层需要的数据也就是最终要的数据，还有未上层提供数据的数据源层，这样做就保证了上层很轻，对上层的框架依赖性就很少。使得业务框架能够保持中立。
而最终成本也在于数据源的维护和管理。这里也存在着一个问题，怎么保证数据源的完整性以及可维护性。虽然徐飞大大在前面通过RxJs来解决前面几个问题，但是实际项目中还是有很多人一起维护，所以要有团队约束，才能实施起来。比如说我上层有个小需求，可以直接通过ajax去获取数据了，就跳过了数据源了。o(╯□╰)o