支付宝前端架构的涅槃 � 

承玉，加缪 � 

大纲 � 

•  历史 � 

•  下一代前端架构 � 

•  实践 � 

•  展望 � 

支付宝前端架构 � 

•  2012 � ~ � 2014 � – seajs � & � arale2 � 

•  2014 � ~ �  �  � – react � & � roof � 

2012 � ~ � 2014 � 

2012 � ~ � 2014 � 

•  技术特点 � – 基于浏览器动态加载的模块化 � 

•  url � combo � •  build � 

– 基于 � jQuery � 面向 � DOM � 的编程方式 � •  初步的组件编写规范 � 

– 提供细粒度的基础模块支持 � 

2012 � ~ � 2014 � 

使用 � 

定义 � 

2012 � ~ � 2014 � 

•  mvc � 组件 � – Model: � attrs � – View: � handlebars � – Control: � events � 

问题 � •  浏览器端加载逻辑过重 � – 无法语义化版本 � 

•  组件机制不完善 � – 模版与局部刷新 � – 组合性 � – 和 � DOM � 节点的结合 � 

•  流行功能缺失 � – 数据绑定 � – … � 

•  专有源不便与业界接轨 � 

2014 � ~ �  � 

•  重新思考~~ � 

history

•  Inspired  by  XHP(php),  2010  开源

history

•  react  2013.8  开源  •   人物  –  Jordan  Walke  @jordwalke  第一版，目前 react-­‐naEve.  G  

–  Pete  Hunt  @floydophone  早期开源版本贡献者.  ig,G  –  SebasEan  Markbåge  @sebmarkbage  目前主力，决策制定.  G  tc39  

–  Paul  O’Shannessy  @zpao  PM.  Fb  –  Tom  Occhino  @tomocchino  manager

React � 

•  Component � –  jsx � – Virtual � DOM � – Life � cycle � 

•  Flux � 

•  Isomorphic � javascript � 

Component � 

Component � 

•  Jsx � 

•  扩充 � es6 � PrimaryExpression � => � JSXElement � JSXAttributeValue � => � { � AssignmentExpression � } � JSXChild � => � {AssignmentExpression �  � } � || � JSXElement � JSXChildren � => � JSXChild � JSXChildren �  � 

Virtual � DOM � 

Dom � diff � 

Virtual � dom � 

•  化动为静，可预测 � – 某一时刻的状态对应于确定的虚拟 � dom � 表示 � – 避免人肉追踪随时间而产生得 � dom � 局部变化 � 

•  框架负责经可能高效得在虚拟 � dom � 和原生 � dom � 间同步 � 

•  * � 抽象层和具体实现脱离，底层可切换为 � canvas/svg/native/dom � 

Life � cycle � 

•  在组件的不同生命周期会调用不同的组件函数 � 

•  初次创建时 � – constructor �  �  � // � server � and � client � – componentWillMount � // � server � and � client � – render �  � // � server � and � client � – componentDidMount � // � client � – componentWillUnmount � // � client � 

Life � cycle � 

•  组件更新 �  � – 父组件重新渲染该组件 � – 本身 � setState � 

•  函数调用顺序 � (client) � – componentWillReceiveProps � – shouldComponentUpdate � – componentWillUpdate � – render � – componentDidUpdate � 

flux � 

•  Single-direction � data � flow � application � pattern � – Action � – Dispatcher � – Store � – View � 

dispatcher

store

view

acEon

推崇的原则 � 

•  单向数据流 � 

•  组件组合 � 

•  可预测，可靠，容易测试 � 

•  声明式语法 � 

Isomorphic �  � •  服务器端渲染 � – React.renderString � 

•  逻辑共享 � – UI � 无关的业务逻辑 � – Router � 路由 � – Validator � 验证 � – Data � model � 数据模型 � 

•  前后端一致的开发模式 � 

 

React  at  alipay

下一代前端架构 � 

commonjs � 

•  具备凌乱生命力的 � commonjs � 生态圈: � npm � 

React � component � 

•  基于 � commonjs � 生态圈的 � react � 生态 � 

react-component � •  基础设施 � –  加载 � npm � 模块 � –  代码检测 � –  测试，覆盖率，示例页面/脚手架自动生成 � –  travis, � saucelabs � 支持 � 

•  目录结构 � –  assets: �  � less � 源码 � –  examples: � 组件示例 � –  lib: � commonjs � 源码 � –  tests: � 测试代码 � 

lib � 

•  源码示例 � – es6: � 动态转化为 � es5 � 到浏览器执行，通过 � 

sourcemap � 支持源码调试 � – require � node_modules � 模块 � 

lib � 

lib � 

•  浏览器实际 � 

examples � 

•  No � html, � Just � js � 

examples � 

•  页面自动生成 � 

tests � 

•  基于 � mocha � •  commonjs � 格式 � 

tests � 

•  覆盖率自动生成 � 

持续集成支持 � 

•  travis, � coveralls, � saucelabs � 

组件开发的一点经验 � •  职责清晰 � 

•  扁平访问 � 

•  避免信息冗余 � 

•  概念一致 � 

•  标签化 � 

•  避免使用 � ref � 

职责清晰

•  多个组件协同完成一件事情，而不是一个组件替其他组件完成本该它自己完成的事情。  

扁平访问

•  组件推荐使用状态来控制交互和显示，如果需要显示访问，也尽量实行扁平访问，即只可以调用其 children  的方法。

避免信息冗余

•  尽量避免信息冗余，如果某个 state  可以由其他 state  计算得到，那么就删除这个 state.

概念一致

•  如果 api  可以和已知概念保持一致，那么就用已知的 api

标签化

•  尽量使用标签嵌套而不是属性配置。

避免使用  ref

•  不要关注细节，使用父组件的  state  控制子组件的状态而不是直接通过  ref  操作子组件

实际项目实践 � 

� •  开发 � 

•  部署 � 

技术栈

•  server:  chair(koa)  

•  生态圈/源:  tnpm(npm)  

•  组件:  react-­‐component(react)  

•  应用架构:  flux  

•  工具:  webpack  

开发 � 

•  nodejs � (chair/koa) � – koa-webpack-dev-middleware: � webpack � 实

时内存打包 � 

package.json

•  devDependencies

开发源码 � 

•  commonjs � – es6 � 同 � react-component � – css/less � 也通过 � require(‘xx.css’) � 加载 � 

页面 � 

•  一个页面一个顶层组件 � App � 组合其他组件 � 

构建数据模型 � 

•  flux � store � 

更新 � 

•  数据模型发生变化时顶层 � App � 重新渲染 � – 数据传递: � 顶层组件－子组件－孙子组件 � – 父子组件互相耦合 �  � 

•  最简单的做法 � •  最高效？ � 

部署 � 

•  使用 � webpack � 进行 � build � – 每个页面打包出一个 � css � 一个 � js，不依赖浏览

器端 � loader � – 通过 � sourcemap � 可以在线调试源码 �  � 

部署

•  Webpack  的一些其他特性  – 排除公共库的打包，react，jquery  可以单独引  

– 通过定义常量，将开发中的  log  在线上删除  •  if(__DEV__)  {  console.log(‘xxx’)  }  

– 抽取多页面的公用依赖模块为单独 js，加强跨页面缓存  

– 将按需加载的模块打包成单独的 js，按需加载

总结

•  组件化开发  –  越细越好  

•  中央数据模型  –  易于理解  

•  前后端一致的开发模式  –  基于  npm  包管理  –  js  为中心  –  项目代码独立  (业务同组件整体打包)  

•  不适合?  –  复杂动态场景（店铺装修？）  

展望 � •  tnpm � 

•  alipay � roof � 

•  Isomorphic �  � 

•  react-art � 

•  react-native � 

tnpm � 

•  Private � package � – @alipay/xx � 

•  npm � package � – 同步自 � npm，内网速度快 � 

•  快速拼装收银台应用 � 

Alipay � roof � 

Isomorphic � 

•  同构  javascript  – 通过 react-­‐router  共享路由  – 通过 fluxible  共享  store  – 通过  alipay  roof  共享模型与验证  – 通过  react  共享渲染

react-­‐art

•  用标签化来实现 canvas  与 svg  •  Svg  – Pro:  结构化易理解，支持事件  – Con:  性能  

•  Canvas  – Pro:  性能高  – 非结构化，无事件  

•  react-­‐art:  svg+canvas  

react-­‐art  demo

react-­‐art

•  hep://yiminghe.me/learning-­‐react/example/react-­‐art/index-­‐build.html  

react-­‐naEve

•  使用 js  来描述界面，布局（flexbox），处理逻辑。单独的线程运行  javascriptcore。  

•  naEve  用来渲染组件，和  javascriptcore  通信。

Ref

•  React:  hep://facebook.github.io/react  •  React-­‐component:  heps://github.com/react-­‐component  

•  Learning-­‐react:  heps://github.com/yiminghe/learning-­‐react  

•  react-­‐webpack-­‐chair:  •  hep://gitlab.alibaba-­‐inc.com/chengyu/chair-­‐react-­‐webpack