2016-我的前端之路:工具化与工程化
前言二十载光辉岁月
近年来，随着浏览器性能的提升与移动互联网浪潮的汹涌而来，Web前端开发进入了高歌猛进，日新月异的时代。这是最好的时代，我们永远在前行，这也是最坏的时代，无数的前端开发框架、技术体系争妍斗艳，让开发者们陷入困惑，乃至于无所适从。Web前端开发可以追溯于1991年蒂姆·伯纳斯-李公开提及HTML描述，而后1999年W3C发布HTML4标准，这个阶段主要是BS架构，没有所谓的前端开发概念，网页只不过是后端工程师的顺手之作，服务端渲染是主要的数据传递方式。接下来的几年间随着互联网的发展与REST等架构标准的提出，前后端分离与富客户端的概念日渐为人认同，我们需要在语言与基础的API上进行扩充，这个阶段出现了以jQuery为代表的一系列前端辅助工具。2009年以来，智能手机开发普及，移动端大浪潮势不可挡，SPA单页应用的设计理念也大行其道，相关联的前端模块化、组件化、响应式开发、混合式开发等等技术需求甚为迫切。这个阶段催生了Angular 1、Ionic等一系列优秀的框架以及AMD、CMD、UMD与RequireJS、SeaJS等模块标准与加载工具，前端工程师也成为了专门的开发领域，拥有独立于后端的技术体系与架构模式。而近两年间随着Web应用复杂度的提升、团队人员的扩充、用户对于页面交互友好与性能优化的需求，我们需要更加优秀灵活的开发框架来协助我们更好的完成前端开发。这个阶段涌现出了很多关注点相对集中、设计理念更为优秀的框架，譬如React、VueJS、Angular 2等组件框架允许我们以声明式编程来替代以DOM操作为核心的命令式编程，加快了组件的开发速度，并且增强了组件的可复用性与可组合性。而遵循函数式编程的Redux与借鉴了响应式编程理念的MobX都是非常不错的状态管理辅助框架，辅助开发者将业务逻辑与视图渲染剥离，更为合理地划分项目结构，更好地贯彻单一职责原则与提升代码的可维护性。在项目构建工具上，以Grunt、Gulp为代表的任务运行管理与以Webpack、Rollup、JSPM为代表的项目打包工具各领风骚，帮助开发者更好的搭建前端构建流程，自动化地进行预处理、异步加载、Polyfill、压缩等操作。而以NPM/Yarn为代表的依赖管理工具一直以来保证了代码发布与共享的便捷，为前端社区的繁荣奠定了重要基石。 纷扰之虹笔者在前两天看到了Thomas Fuchs的一则Twitter，也在Reddit等社区引发了热烈的讨论：我们用了15年的时间来分割HTML、JS与CSS，然而一夕之间事务仿佛回到了原点。 总结而言，目前前端工具化已经进入到了非常繁荣的时代，随之而来很多前端开发者也甚为苦恼，疲于学习。工具的变革会非常迅速，很多优秀的工具可能都只是历史长河中的一朵浪花，而蕴藏其中的工程化思维则会恒久长存。无论你现在使用的是React还是Vue还是Angular 2或者其他优秀的框架，都不应该妨碍我们去了解尝试其他，笔者在学习Vue的过程中感觉反而加深了自己对于React的理解，加深了对现代Web框架设计思想的理解，也为自己在未来的工作中更自由灵活因地制宜的选择脚手架开阔了视野。 引言的最后，我还想提及一个词，算是今年我在前端领域看到的出镜率最高的一个单词：Tradeoff（妥协）。 工具化
月盈而亏，过犹不及。相信很多人都看过了2016年里做前端是怎样一种体验这篇文章，2016年的前端真是让人感觉从入门到放弃，我们学习的速度已经跟不上新框架新概念涌现的速度，用于学习上的成本远大于实际开发项目的成本。不过笔者对于工具化的浪潮还是非常欢迎的，我们不一定要去用最新最优秀的工具，但是我们有了更多的选择余地，相信这一点对于大部分非处女座人士而言都是喜讯。年末还有一篇曹刘阳：2016年前端技术观察也引发了大家的热议，老实说笔者个人对文中观点认同度一半对一半，不想吹也不想黑。不过笔者看到这篇文章的第一感觉当属作者肯定是大公司出来的。文中提及的很多因为技术负债引发的技术选型的考虑、能够拥有相对充分完备的人力去进行某个项目，这些特征往往是中小创公司所不会具备的。 工具化的意义工具化是有意义的。笔者在这里非常赞同尤雨溪：Vue 2.0，渐进式前端解决方案 的思想，工具的存在是为了帮助我们应对复杂度，在技术选型的时候我们面临的抽象问题就是应用的复杂度与所使用的工具复杂度的对比。工具的复杂度是可以理解为是我们为了处理问题内在复杂度所做的投资。为什么叫投资？那是因为如果投的太少，就起不到规模的效应，不会有合理的回报。这就像创业公司拿风投，投多少是很重要的问题。如果要解决的问题本身是非常复杂的，那么你用一个过于简陋的工具应付它，就会遇到工具太弱而使得生产力受影响的问题。反之，是如果所要解决的问题并不复杂，但你却用了很复杂的框架，那么就相当于杀鸡用牛刀，会遇到工具复杂度所带来的副作用，不仅会失去工具本身所带来优势，还会增加各种问题，例如培训成本、上手成本，以及实际开发效率等。
笔者在GUI应用程序架构的十年变迁:MVC,MVP,MVVM,Unidirectional,Clean一文中谈到，所谓GUI应用程序架构，就是对于富客户端的代码组织/职责划分。纵览这十年内的架构模式变迁，大概可以分为 工具化的不足：抽象漏洞定理抽象漏洞定理是Joel在2002年提出的，所有不证自明的抽象都是有漏洞的。抽象泄漏是指任何试图减少或隐藏复杂性的抽象，其实并不能完全屏蔽细节，试图被隐藏的复杂细节总是可能会泄漏出来。抽象漏洞法则说明：任何时候一个可以提高效率的抽象工具，虽然节约了我们工作的时间，但是，节约不了我们的学习时间。我们在上一章节讨论过工具化的引入实际上以承受工具复杂度为代价消弭内在复杂度，而工具化滥用的结局即是工具复杂度与内在复杂度的失衡。 谈到这里我们就会明白，不同的项目具备不同的内在复杂度，一刀切的方式评论工具的好坏与适用简直耍流氓，而且我们不能忽略项目开发人员的素质、客户或者产品经理的素质对于项目内在复杂度的影响。对于典型的小型活动页，譬如某个微信H5宣传页，往往注重于交互动画与加载速度，逻辑复杂度相对较低，此时Vue这样渐进式的复杂度较低的库就大显身手。而对于复杂的Web应用，特别是需要考虑多端适配的Web应用，笔者会倾向于使用React这样相对规范严格的库。 React？Vue？Angular 2？
笔者最近翻译过几篇盘点文，发现很有趣的一点，若文中不提或没夸Vue，则一溜的评论：垃圾文章，若文中不提或没夸Angular 2，则一溜的评论：垃圾文章。估计若是笔者连React也没提，估计也是一溜的评论：垃圾文章。好吧，虽然可能是笔者翻译的确实不好，玷污了原文，但是这种戾气笔者反而觉得是对于技术的不尊重。React，Vue，Angular 2都是非常优秀的库与框架，它们在不同的应用场景下各自具有其优势，本章节即是对笔者的观点稍加阐述。Vue最大的优势在于其渐进式的思想与更为友好的学习曲线，Angular 2最大的优势其兼容并包形成了完整的开箱即用的All-in-one框架，而这两点优势在某些情况下反而也是其劣势，也是部分人选用React的理由。笔者觉得很多对于技术选型的争论乃至于谩骂，不一定是工具的问题，而是工具的使用者并不能正确认识自己或者换位思考他人所处的应用场景，最终吵的驴唇不对马嘴。 小而美的视图层React 与 VueJS 都是所谓小而美的视图层Library，而不是Angular 2这样兼容并包的Frameworks。任何一个编程生态都会经历三个阶段，第一个是原始时期，由于需要在语言与基础的API上进行扩充，这个阶段会催生大量的Tools。第二个阶段，随着做的东西的复杂化，需要更多的组织，会引入大量的设计模式啊，架构模式的概念，这个阶段会催生大量的Frameworks。第三个阶段，随着需求的进一步复杂与团队的扩充，就进入了工程化的阶段，各类分层MVC，MVP，MVVM之类，可视化开发，自动化测试，团队协同系统。这个阶段会出现大量的小而美的Library。 函数式思维：抽象与直观近年来随着应用业务逻辑的日益复杂与并发编程的大规模应用，函数式编程在前后端都大放异彩。软件开发领域有一句名言：可变的状态是万恶之源，函数式编程即是避免使用共享状态而避免了面向对象编程中的一些常见痛处。不过老实说笔者并不想一味的推崇函数式编程，在下文关于Redux与MobX的讨论中，笔者也会提及函数式编程不可避免地会使得业务逻辑支离破碎，反而会降低整个代码的可维护性与开发效率。与React相比，Vue则是非常直观的代码架构，每个Vue组件都包含一个script标签，这里我们可以显式地声明依赖，声明操作数据的方法以及定义从其他组件继承而来的属性。而每个组件还包含了一个template标签，等价于React中的render函数，可以直接以属性方式绑定数据。最后，每个组件还包含了style标签而保证了可以直接隔离组件样式。我们可以先来看一个典型的Vue组件，非常直观易懂，而两相比较之下也有助于理解React的设计思想。 <script>
export default {
components: {},data() {
return {
notes: [],};
},created() {
this.fetchNotes();
},methods: {
addNote(title,body,createdAt,flagged) {
return database('notes').insert({ title,created_at: createdAt,flagged });
},};
</script>
<template>
<div class="app">
<header-menu
:addNote='addNote'
>
</div>
</template>
<style scoped>
.app {
width: 100%;
height: 100%;
postion: relative;
}
</style>
当我们将视角转回到React中，作为单向数据绑定的组件可以抽象为如下渲染函数: View = f(Data) 这种对用户界面的抽象方式确实令笔者耳目一新，这样我们对于界面的组合搭配就可以抽象为对于函数的组合，某个复杂的界面可以解构为数个不同的函数调用的组合变换。0.14版本时，React放弃了MixIn功能，而推荐使用高阶函数模式进行组件组合。这里很大一个考虑便是Mixin属于面向对象编程，是多重继承的一种实现，而函数式编程里面的Composition（合成）可以起到同样的作用，并且能够保证组件的纯洁性而没有副作用。 很多人第一次学习React的时候都会觉得JSX语法看上去非常怪异，这种背离传统的HTML模板开发方式真的靠谱吗？（在2.0版本中Vue也引入了JSX语法支持）。我们并不能单纯地将JSX与传统的HTML模板相提并论，JSX本质上是对于 在现代浏览器中，对于JavaScript的计算速度远快于对DOM进行操作，特别是在涉及到重绘与重渲染的情况下。并且以JavaScript对象代替与平台强相关的DOM，也保证了多平台的支持，譬如在ReactNative的协助下我们很方便地可以将一套代码运行于iOS、Android等多平台。总结而言，JSX本质上还是JavaScript，因此我们在保留了JavaScript函数本身在组合、语法检查、调试方面优势的同时又能得到类似于HTML这样声明式用法的便利与较好的可读性。 前后端分离与全栈:技术与人
前后端分离与全栈并不是什么新鲜的名词，都曾引领一时风骚。五年前笔者初接触到前后端分离的思想与全栈工程师的定义时，感觉醍醐灌顶，当时的自我定位也是希望成为一名优秀的全栈工程师，不过现在想来当时的自己冠以这个名头更多的是为了给什么都了解一点但是都谈不上精通，碰到稍微深入点的问题就手足无措的自己的心理安慰罢了。Web前后端分离优势显著，对于整个产品的开发速度与可信赖性有着很大的作用。全栈工程师对于程序员自身的提升有很大意义，对于项目的初期速度有一定增速。如果划分合理的话能够促进整个项目的全局开发速度与可信赖性，但是如果划分不合理的话只会导致项目接口混乱，一团乱麻。但是这两个概念似乎略有些冲突，我们常说的前后端分离会包含以下两个层面：
前后端分离本质上是前端与后端适用不同的技术选型与项目架构，不过二者很多思想上也是可以融会贯通，譬如无论是响应式编程还是函数式编程等等思想在前后端皆有体现。而全栈则无论从技术还是组织架构的划分上似乎又回到了按照需求分割的状态。不过呢，我们必须要面对现实，很大程度的工程师并没有能力做到全栈，这一点不在于具体的代码技术，而是对于前后端各自的理解，对于系统业务逻辑的理解。如果我们分配给一个完整的业务块，同时，那么最终得到的是无数个碎片化相互独立的系统。 相辅相成的客户端渲染与服务端渲染
笔者在2015-我的前端之路提及最初的网页是数据、模板与样式的混合，即以经典的APS.NET、PHP与JSP为例，是由服务端的模板提供一系列的标签完成从业务逻辑代码到页面的流动。所以，前端只是用来展示数据，所谓附庸之徒。而随着Ajax技术的流行，将WebAPP也视作CS架构，抽象来说，会认为CS是客户端与服务器之间的双向通信，而BS是客户端与服务端之间的单向通信。换言之，网页端本身也变成了有状态。从初始打开这个网页到最终关闭，网页本身也有了一套自己的状态，而拥有这种变化的状态的基础就是AJAX，即从单向通信变成了双向通信。图示如下：
上文描述的即是前后端分离思想的发展之路，而近两年来随着React的流行服务端渲染的概念重回人们的视线。需要强调的是，我们现在称之为服务端渲染的技术并非传统的以JSP、PHP为代表的服务端模板数据填充，更准确的服务端渲染作用的描述是对于客户端应用的预启动与预加载。我们千方百计将客户端代码拉回到服务端运行并不是为了替换现有的API服务器，并且在服务端运行过的代码同样需要在客户端重新运行，这里推荐参考笔者的Webpack2-React-Redux-Boilerplate，按照三个层次地渐进描述了从纯客户端渲染到服务端渲染的迁移之路。引入服务端渲染带来的优势主要在于以下三个方面：
总结而言，服务端渲染与客户端渲染是相辅相成的，在React等框架的协助下我们也可以很方便地为开发阶段的纯客户端渲染应用添加服务端渲染支持。 项目中的全栈工程师:技术全栈，需求隔离，合理分配
全栈工程师对于个人发展有很大的意义，对于实际的项目开发，特别是中小创公司中以进度为第一指挥棒的项目而言更具有非常积极的意义。但是全栈往往意味着一定的Tradeoff，步子太大，容易扯着蛋。任何技术架构和流程的调整，最好都不要去违背康威定律，即设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。这里是笔者在本文第一次提及康威定律，笔者在实践中发现，有些全栈的结果就是强行按照功能来分配任务，即最简单的来说可能把登录注册这一块从数据库设计、服务端接口到前端界面全部分配给一个人或者一个小组完成。然后这个具体的执行者，因为其总体负责从上到下的全部逻辑，在很多应该规范化的地方，特别是接口定义上就会为了求取速度而忽略了必要的规范。最终导致整个系统支离破碎成一个又一个的孤岛，不同功能块之间表述相同意义的变量命名都能发生冲突，各种奇形怪状的id、uuid、{resource}_id令人眼花缭乱。 今年年末的时候，不少技术交流平台上掀起了对于全栈工程师的声讨，以知乎上全栈工程师为什么会招黑这个讨论为例，大家对于全栈工程师的黑点主要在于：
现代经济发展的一个重要特征就是社会分工日益精细明确，想要成为无所不知的通才不过南柯一梦。不过在上面的声讨中我们也可以看出全栈工程师对于个人的发展是及其有意义的，它山之石，可以攻玉，融会贯通方能举一反三。笔者在自己的小团队中很提倡职位轮替，一般某个项目周期完成后会调换部分前后端工程师的位置，一方面是为了避免繁杂的事务性开发让大家过于疲惫。另一方面也是希望每个人都了解对方的工作，这样以后出Bug的时候就能换位思考，毕竟团队内部矛盾，特别是各个小组之间的矛盾一直是项目管理中头疼的问题。
工程化
何谓工程化所谓工程化，即是面向某个产品需求的技术架构与项目组织，工程化的根本目标即是以尽可能快的速度实现可信赖的产品。尽可能短的时间包括开发速度、部署速度与重构速度，而可信赖又在于产品的可测试性、可变性以及Bug的重现与定位。
无论是前后端分离，还是后端流行的MicroService或者是前端的MicroFrontend，其核心都是牺牲局部开发速度换来更快地全局开发速度与系统的可信赖性的提高。而区分初级程序员与中级程序员的区别可能在于前者仅会实现，仅知其然而不知其所以然，他们唯一的衡量标准就是开发速度，即功能实现速度或者代码量等等，不一而足。中级程序员则可以对自己负责范围内的代码同时兼顾开发速度与代码质量，会在开发过程中通过不断地Review来不断地合并分割，从而在坚持SRP原则的基础上达成尽可能少的代码量。另一方面，区分单纯地Coder与TeamLeader之间的区别在于前者更注重局部最优，这个局部即可能指项目中的前后端中的某个具体模块，也可能指时间维度上的最近一段的开发目标。而TeamLeader则更需要运筹帷幄，统筹全局。不仅仅要完成老板交付的任务，还需要为产品上可能的修改迭代预留接口或者提前为可扩展打好基础，磨刀不误砍材工。总结而言，当我们探究工程化的具体实现方案时，在技术架构上，我们会关注于：
前端的工程化需求当我们落地到前端时，笔者在历年的实践中感受到以下几个突出的问题：
归纳到具体的技术点，我们可以得出如下衍化图： 声明式的渲染或者说可变的命令式操作是任何情况下都需要的，从以DOM操作为核心到数据流驱动能够尽量减少冗余代码，提高开发效率。笔者在这里还是想以jQuery与Angular 1的对比为例： var options = $("#options");
$.each(result,function() {
options.append($("<option />").val(this.id).text(this.name));
});
<div ng-repeat="item in items" ng-click="select(item)">{{item.name}}
</div>
目前React、Vue、Angular 2或其扩展中都提供了基于ES6的声明式组件的支持，那么在基本的声明式组件之上，我们就需要构建可复用、可组合的组件系统，往往某个组件系统是由我们某个应用的大型界面切分而来的可空单元组合而成，也就是下文前端架构中的解构设计稿一节。当我们拥有大型组件系统，或者说很多的组件时，我们需要考虑组件之间的跳转。特别是对于单页应用，我们需要将URL对应到应用的状态，而应用状态又决定了当前展示的组件。这时候我们的应用日益复杂，当应用简单的时候，可能一个很基础的状态和界面映射可以解决问题，但是当应用变得很大，涉及多人协作的时候，就会涉及多个组件之间的共享、多个组件需要去改动同一份状态，以及如何使得这样大规模应用依然能够高效运行，这就涉及大规模状态管理的问题，当然也涉及到可维护性，还有构建工具。现在，如果放眼前端的未来，当HTTP2普及后，可能会带来构建工具的一次革命。但就目前而言，尤其是在中国的网络环境下，打包和工程构建依然是非常重要且不可避免的一个环节。
MicroFrontend：微前端
微服务为构建可扩展、可维护的大规模服务集群带来的便利已是毋庸置疑，而现在随着前端应用复杂度的日渐提升，所谓的巨石型的前端应用也是层出不穷。而与服务端应用程序一样，大型笨重的Web应用同样是难以维护，因此ThoughtWorks今年提出了所谓MicroFrontend微前端的概念。微前端的核心思想和微服务殊途同归，巨型的Web应用根据页面与功能进行切分，不同的团队负责不同的部分，每个团队可以根据自己的技术喜好应用相关的技术来开发相关部分，这里BFF - backend for frontends也就派上了用场。 回归现实的前端开发计划本文的最后一个部分着眼于笔者一年中实践规划出的前端开发计划，估计本文只是提纲挈领的说一下，未来会有专门的文章进行详细介绍。缘何称之为回归现实的前端开发计划？是因为笔者感觉遇见的最大的问题在于需求的不明确、接口的不稳定与开发人员素质的参差不齐。先不论技术层面，项目开发中我们在组织层面的希望能让每个参与的人无论水平高低都能最大限度的发挥其价值，每个人都会写组件，都会写实体类，但是他们不一定能写出合适的优质的代码。另一方面，好的架构都是衍化而来，不同的行业领域、应用场景、界面交互的需求都会引发架构的衍化。我们需要抱着开放的心态，不断地提取公共代码，保证合适的复用程度。同时也要避免过度抽象而带来的一系列问题。笔者提倡的团队合理搭配方式如下，这个更多的是面向于小型公司，人手不足，一个当两个用，恨不得所有人都是全栈： 声明式编程与数据流驱动：有得有失
Redux是完全的函数式编程思想践行者（如果你对于Redux还不够理解，可以参考下笔者的深入理解Redux:10个来自专家的Redux实践建议），其核心技术围绕遵循Pure Function的Reducer与遵循Immutable Object的Single State Tree，提供了Extreme Predictability与Extreme Testability，相对应的需要大量的Boilerplate。而MobX则是Less Opinioned，其脱胎于Reactive Programming，其核心思想为Anything that can be derived from the application state,should be derived. Automatically，即避免任何的重复状态。Redux使用了Uniform Single State Tree，而在后端开发中习惯了Object Oriented Programming的笔者不由自主的也想在前端引入Entity，或者说在设计思想上，譬如对于TodoList的增删改查，笔者希望能够包含在某个TodoList对象中，而不需要将所有的操作拆分为Creator、Reducer与Selector三个部分，我只是想简单的展示个列表而已。笔者上大学学的第一节课就是讲OOP，包括后面在C#、Java、Python、PHP等等很多后端领域的实践中，都深受OOP思想的熏陶与灌输。不可否认，可变的状态是软件工程中的万恶之源，但是，OOP对于业务逻辑的描述与代码组织的可读性、可理解性的保证相较于声明式的，略为抽象的FP还是要好一点的。我认可函数式编程的思想成为项目构建组织的不可分割的一部分，但是是否应该在任何项目的任何阶段都先谈编程思想，而后看业务需求？这无疑有点政治正确般的耍流氓了。Dan推荐的适用Redux的情况典型的有：
渐进的状态管理
在不同的时间段做不同的事情，当我们在编写纯组件阶段，我们需要显式声明所有的状态/数据，而对于Action则可以放入Store内延后操作。以简单的表单为例，最初的时候我们会将表单的数据输入、验证、提交与结果反馈等等所有的逻辑全部封装在表单组件内。而后随着组件复杂度的增加，我们需要针对不同功能的代码进行切分，此时我们就可以建立专门的Store来处理该表单的状态与逻辑。抽象来说，我们在不同的阶段所需要的状态管理对应为：
这个阶段我们可能直接将数据获取的函数放置到componentDidMount中，并且将UI State与Domain State都利用setState函数存放在LocalState中。这种方式的开发效率最高，毕竟代码量最少，不过其可扩展性略差，并且不利于视图之间共享状态。 // component
<button onClick={() => store.users.push(user)} />
这里的store仅仅指纯粹的数据存储或者模型类。
随着项目逐渐复杂化，我们需要寻找专门的状态管理工具来进行外部状态的管理了: // component
<button onClick={() => store.addUser(user)} />
// store
@action addUser = (user) => {
this.users.push(user);
}
这个时候你也可以直接在组件内部修改状态，即还是使用第一个阶段的代码风格，直接操作store对象，不过也可以通过引入Strict模式来避免这种不良好的实践: // root file
import { useStrict } from 'mobx';
useStrict(true);
随着项目体量进一步的增加与参与者的增加，这时候使用声明式的Actions就是最佳实践了，也应该是Redux闪亮登场的时候了。这时候Redux本来最大的限制，只能通过Action而不能直接地改变应用状态也就凸显出了其意义所在（Use Explicit Actions To Change The State）。 // reducer (state,action) => newState 渐进的前端架构笔者心中的前端架构如下所示，这里分别按照项目的流程与不同的开发时间应该开发的模块进行说明：
解构设计稿
纯组件在解构设计稿之后，我们需要总结出其中的纯组件，此时所谓的StoryBook Driven Development就派上了用场，譬如笔者总结出Material UI Extension这个通用类库。 实体类实体类其实就是静态类型语言，从工程上的意义而言就是可以统一数据规范，笔者在上文中提及过康威定律，设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。实体类，再辅以类似于TypeScript、Flow这样的静态类型检测工具，不仅可以便于IDE进行语法提示，还能尽可能地避免静态语法错误。同时，当业务需求发生变化，我们需要重组织部分业务逻辑，譬如修改某些关键变量名时，通过统一的实体类可以更方便安全地进行修改。同时，我们还需要将部分逻辑放置到实体类中进行，典型的譬如状态码与其描述文本之间的映射、部分静态变量值的计算等： //零件关联的图纸信息
models: [ModelEntity] = [];
cover: string = '';
/**
* @function 根据推导出的零件封面地址
*/
get cover() {
//判断是否存在图纸信息
if (this.models && this.models.length > 0 && this.models[0].image) {
return this.models[0].image;
}
return 'https://coding.net/u/hoteam/p/Cache/git/raw/master/2016/10/3/demo.png';
}
同时在实体基类中，我们还可以定义些常用方法: /**
* @function 所有实体类的基类,命名为EntityBase以防与DOM Core中的Entity重名
*/
export default class EntityBase {
//实体类名
name: string = 'defaultName';
//默认构造函数,将数据添加到当前类中
constructor(data,self) {
//判断是否传入了self,如果为空则默认为当前值
self = self || this;
}
// 过滤值为null undefined '' 的属性
filtration() {
const newObj = {};
for (let key in this) {
if (this.hasOwnProperty(key) && this[key] !== null && this[key] !== void 0 && this[key] !== '') {
newObj[key] = this[key];
}
}
return newObj;
}
/**
* @function 仅仅将类中声明存在的属性复制进来
* @param data
*/
assignProperties(data = {}) {
let properties = Object.keys(this);
for (let key in data) {
if (properties.indexOf(key) > -1) {
this[[key]] = data[[key]];
}
}
}
/**
* @function 统一处理时间与日期对象
* @param data
*/
parseDateProperty(data) {
if (!data) {
return
}
//统一处理created_at、updated_at
if (data.created_at) {
if (data.created_at.date) {
data.created_at.date = parseStringToDate(data.created_at.date);
} else {
data.created_at = parseStringToDate(data.created_at);
}
}
if (data.updated_at) {
if (data.updated_at.date) {
data.updated_at.date = parseStringToDate(data.updated_at.date)
} else {
data.updated_at = parseStringToDate(data.updated_at);
}
}
if (data.completed_at) {
if (data.completed_at.date) {
data.completed_at.date = parseStringToDate(data.completed_at.date);
} else {
data.completed_at = parseStringToDate(data.completed_at);
}
}
if (data.expiration_at) {
if (data.expiration_at.date) {
data.expiration_at.date = parseStringToDate(data.expiration_at.date);
} else {
data.expiration_at = parseStringToDate(data.expiration_at);
}
}
}
/**
* @function 将类以JSON字符串形式输出
*/
toString() {
return JSON.stringify(Object.keys(this));
}
/**
* @function 生成随机数
* @return {string}
* @private
*/
_randomNumber() {
let result = '';
for (let i = 0; i < 6; i++) {
result += Math.floor(Math.random() * 10);
}
return result;
}
}
接口接口主要是负责进行数据获取，同时接口层还有一个职责就是对上层屏蔽服务端接口细节，进行接口组装合并等。笔者主要是使用总结出的Fluent Fetcher，譬如我们要定义一个最常见的登录接口： /**
* 通过邮箱或手机号登录
* @param account 邮箱或手机号
* @param password 密码
* @returns {UserEntity}
*/
async loginByAccount({account,password}){
let result = await this.post('/login',{
account,password
});
return {
user: new UserEntity(result.user),token: result.token
};
}
建议开发人员接口写好后，直接简单测试下： let accountAPI = new AccountAPI(testUserToken);
accountAPI.loginByAccount({account:'wyk@1001hao.com',password:'1234567'}).then((data) => {
console.log(data);
});
这里直接使用 容器/高阶组件容器往往用于连接状态管理与纯组件，笔者挺喜欢IDE的LiveTemplating功能的，典型的容器模板为: // @flow
import React,{ Component,PropTypes } from 'react';
import { push } from 'react-router-redux';
import { connect } from 'react-redux';
/**
* 组件ContainerName,用于展示
*/
@connect(null,{
pushState: push,})
export default class ContainerName extends Component {
static propTypes = {};
static defaultProps = {};
/**
* @function 默认构造函数
* @param props
*/
constructor(props) {
super(props);
}
/**
* @function 组件挂载完成回调
*/
componentDidMount() {
}
/**
* @function 默认渲染函数
*/
render() {
return <section className="">
</section>
}
}
服务端渲染与路由服务端渲染与路由可以参考Webpack2-React-Redux-Boilerplate。 线上质量保障：前端之难，不在前端前端开发完成并不意味着万事大吉，笔者在一份周报中写道，我们目前所谓的Bug往往有如下三类： 线上质量保障，往往面对的是很多不可控因素，譬如公司邮件服务欠费而导致注册邮件无法发出等问题，笔者建立了frontend-guardian，希望在明年一年内予以完善：
frontend-guardian希望能是尽量简单的实时监控与回归测试工具，大公司完全可以自建体系或者基于Falcon等优秀的工具扩展，不过小公司特别是在创业初期希望尽可能地以较小的代价完成线上质量保障。 延伸阅读
后记2016年末如往昔一般很多优秀的总结盘点文章涌现了出来，笔者此文也是断断续续写了好久，公司项目急着上线，毕业论文也是再不写就要延期的节奏。这段时间笔者看了很多大家之作后越发觉得自己的格局与眼光颇低，这也是笔者一直在文中提及我的经验与感触更多的来自于中小创团队，希望明年能够有机会进一步开拓视野。如果哪位阅读本文的伙伴有好的交流群推荐欢迎私信告知，三人行，必有我师，笔者也是希望能够接触一些真正的大神。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |