本期看点：React + Redux 前端第三方交互 手 Q 家校群

 

导读：

 

首届 AC2015 大会即将于 2015 年 12 月 12 日在深圳腾讯大厦总部举行。这是 AlloyTeam 沉寂一年来首次对外举行的一次技术分享。AlloyTeam 前身是负责 WebQQ，Q+，QQ 互联的腾讯前端团队，最近又历经了兴趣部落、群开放、家校群等一连串 QQ 拳头项目的洗礼，积淀了不少技术知识，希望借着一年一度的技术分享会对外展示我们一年以来的技术成果。届时，亦会有神秘 web 游戏项目对外公布。

 

潘佳韩，AC2015 的首位讲师，2012 年加入腾讯 AlloyTeam，曾参与过兴趣部落、群活动等项目的开发，目前是手 Q 家校群项目的前端主要负责人，参与项目期间，制定了家校群移动端详情页功能、题库功能、PC 家校群功能的交互及技术方案，保证家校群功能的稳定上线，以及对内推广 react + redux 技术。

 

Github： https://github.com/weberpan

项目：http://www.ipresst.com/

 

图一：iPresst 首页星空图

 

 

问题 1： 介绍一下你自己？例如，昵称，什么时候在哪里毕业，什么系，有什么前端作品

 

我叫潘佳韩，江湖人称老教授，教授是教授的教教授的授，别误会。来自珠江之滨可以遥望小蛮腰的大学，学的是大家觉得除了做数学老师没有别的工作对口的数学，后来因为一番机缘巧合，加入 AlloyTeam，踏上前端之路。在腾讯工作的数年间，先后做过 webQQ、Q+、兴趣部落、群活动和家校群等业务，也捣鼓过一些好玩的东西，如主打在线展示的 iPresst 创作平台，如用来折腾人的前端闯关游戏“ 前端特工” 和“ 前端突击队”（如被虐过，请轻拍板砖，哈哈）。

 

 

问题 2：为什么好好的数学不搞，走上前端这条不归路。

 

同样都是不归路，我只是选了一条女生多一点的路走。

 

 

问题 3： 当初，你是通过什么样的努力才能进入腾讯的，然后又是通过怎么样的努力成为今天人人赞颂的老教授。

 

直到我大四上学期拿到腾讯的 offer，我一直把编程当做副业，我的主业是做基础数学研究。然而生活就是如此奇妙不经意间跟编程结下很多不解之缘。

 

第一次接触编程是高中学 pascal，由于数学基础好逻辑思维也还可以，所以那时候发现写起程序也算得心应手，要知道，你能做好一件事情很容易让你喜欢上它。大学之后虽然是数学系的但我们每学期都有一门计算机课程，C、C++、数据结构的基础也是在那时学到，公选课还学了些单片机编程、函数式编程等。和前端结缘是在大三，加入学院的一个技术社团，从那时我才知道有 PHP+mysql 这种东西，学了之后就被安排做一个社团的简历网站，就这样开始前端之路。还记得一开始还是用 Photoshop 切好图直接导出自动生成 html，就是 table 布局，现在每次想起总是想笑，那时候觉得前端就是这么简单。

 

为什么选择前端呢？这个问题不止我在问自己，我参加百度校招的一面二面三面都被问到，而我的回答是：我喜欢具象的看到的更确切说是好看的东西。或者这就是我不走数学之路的一个原因，高等数学太抽象了，如抽象代数。也因此我喜欢前端远多于后台。而我个人喜欢研究点交互也是同样的道理，因为它是用户可触摸可感受到的具象的，你框架写得再优越用户也感知不到。这是个人性格使然，我想从代码层面去让产品更好用，而我的分享就是我在这个过程中的一点经验。

 

来到腾讯后也很庆幸加入 AlloyTeam 团队，除了有一群同样热爱前端的小伙伴，还有一些业务开发之外的自由项目。可以说我工作后前几年前端进步最快不是因为做业务需求而是因为自由项目，特别是 iPresst ，它让我在前端、后台、PM、PDM、视觉、交互各方面都得到锻炼。而 leader 涛哥又经常帮我们创造各种外部分享机会，如开发者年会、H5 峰会等。也正是这些外部条件让我快速成为大家信 (wu) 任 (yu) 的老教 (xue) 授 (jiu)。

 

 

问题 4： 这次你的讲题关于移动的交互。交互跟用户体验密切相联。工程师要做到极致的前端用户体验，需要有什么要诀。

 

很多人觉得交互是交互设计师要考虑的，关我们前端何事？其实这不对，想把用户体验要做得更好让用户用得更爽，很多时候要从代码层面去优化，交互师不写前端未必懂。

 

对于我们稍微一点经验的前端工程师来说，我觉得最好在交互设计师把效果做出来之前，先跟他们做好沟通，看看他们的想法是否能很好地还原效果，这样能有效节约双方的时间。举个例子，之前在做手 Q 群活动的详情页的时候，有这么一个交互设计：顶部有一个大图背景，上面会有一些活动的地点、时间等基本介绍。当用户滚动的时候，这个大图背景高度随着滚动相应变小，活动的资料也会相应调整其位置。有经验的前端工程师一看，就会知道，由于某些设备的性能问题，没有可能 100% 还原这样的效果，当时交互居然还把交互动画做出来了。我看交互做得这么辛苦，把这个效果的实现分配给了新人，让他认真调研一下。最后只能用一个替代的方案，当滚动条到一定的位置的时候再触发大图背景的变化，而不是逐帧变化。类似的事情其实还发生过不少，交互设计总喜欢追求酷炫，而无视具体实现的效果。有时候恨不得给他们上几堂前端的课，给他们总结一下几大交互设计师喜欢做的，但前端实现起来有困难的效果。

 

另外，想做好交互，我觉得核心不是页面真的快，而是用户感觉快看起来快，有些事我们就躲在幕后默默帮用户做。做过前端项目的人都知道，很多时候，交互设计师只会给你一个设计图，虽然那样已经是非常仔细了，但总是会有很多交互并没有仔细规定，需要前端去拿捏，我们姑且称之为交互设计的灰色地带吧。最常见的就是加载状态，交互设计师并不会规定你什么时候需要加载，因为这涉及具体技术上的具体实现。举个例子，我们做一个叫做先锋教师的运营页面，用来吸引老师使用，页面包含加入页和成功页。如果你将两个功能放在拆成两页面，跳转的时候就需要加载，如果做成同一个页，但另一个页面的资源是按需拉取的，这也需要加载，只有一次加载好的技术实现，可以略去加载这一步。让页面加载，即是让用户等待，我们是希望尽量避免的，但有时候我们无可避免需要取舍，因为如果我们希望用一次加载完这种方案，可能会伤害首屏加载的体验。有时候用户抱怨页面加载太多，其实他们并不知道我们在实施这种方案后面的种种考量。

 

图二：旧版群活动详情页交互

点击微信公众号文查看视频

 

问题 5： 目前你是 QQ 家校群前端的负责人，对于家校群这种教育类的移动应用，在交互上有什么难点，你是怎么样去进行突破的。

 

关于家校群，我觉得重点不是交互的优越性，而是服务的稳定性和可用性。我觉得这跟产品的具体定位有关。试想一下，你是老师布置了个班级作业，但只要有一个学生的手机就是显示异常或网络不行，这时候他做不了作业该怨谁？所以我们更注重稳定性和可用性。

 

关于家校群的交互，家校群的错误提示处理是一个很好的例子。对于其它一些业务来说，错误的提示比较笼统可能并没有什么问题，将之统一为服务器问题或者网络问题对用户来说都并没有什么区别。而针对家校群的用户，准确的错误传递显得尤为重要。例如布置作业的字数是否超过了限制、提交作业的时间是否逾期、题目答案错了在哪里进行反馈。我们做这些错误的提示，并不是简单为了让用户退出页面或者等待服务器恢复，正确的错误反馈是想让用户准确地知道他接下来应该做什么，而减少时间的浪费。除了错误的提示，我们前端有做一套错误码的上报，针对前端的错误，我们会定期进行清理，针对后台的问题，我们会定期跟他们沟通，让他们减少后台接口的失败率。

 

 

问题 6：家校群 PC 功能页面是手 Q 第一个实践 React + Redux 这套框架组合的业务，起用这套新组合的时候你们有什么考量？这套框架有什么优势呢？

 

背景首先是我们一直用着的那些框架在业务扩展越来越大的情况下问题会越来越明显，扩展性较差、模块化的设计有缺陷。其次，我们用这些框架用得太蛮久了，想试用一些新的技术，来带动家校群项目组的技术提升。另外一个原因是因为我们的页面会嵌在 PCQQ 的页面框里，这个框自带 webkit 内核，这样我们可以完全忽略 IE8 或以下的浏览器，因此我们的技术选型可以更大胆。而且，当时 Redux 已经诞生大半年了，技术也逾趋成熟，因此我们跳过了 Flux，Reflux 这些框架直接使用 Redux。不过使用新框架对项目是有风险的，因此我们评估了足够的时候，边做项目边填坑。

 

由于家校群功能页面是一个中等规模的单面应用，因此用 React + Redux 的的优势会比较明显。功能页面分成作业列表、布置作业、作业详情、回答作业、作业分析等几大模块，我们主要使用 webpack 进行开发和编译，将不同模块分拆成不同大组件，大组件下面再细分小组件，组件在复用的时候大大减少了旧有模式的代码量和维护成本。在不同的模块进行交互、切换的时候，只需要发起一个动作 action 就可以进行，比旧的模式更能进行代码解藕和排查错误。

 

如果有兴趣，当天来 AC2015 的时候可以跟我的徒弟 JoeyGuo 进行交流，这个项目他也是主要负责人之一，他到时会在台下跟大家一起交流。

 

图三：文艺老教授

 

图四：老教授与组员

 

更多有关前端交互的内容，请关注 AC 大会。或添加 AlloyTeam 的公众号 AlloyTeam，或搜索 AlloyTeam 的微博。