作为老司机使用 React 总结的 11 个经验教训
原文作者：JolyonRuss
本文编译：胡子大哈翻译原文：http://huziketang.com/blog/posts/detail?postId=58e83f01a58c240ae35bb8e1
英文连接：11lessonslearnedasaReactcontractor
转载请注明出处，保留原文链接以及作者信息
一开始在React路上摸爬滚打的时候，不知道该寻找些什么，但是这些年来，回头总结经验才发现，要找的已经在脑子里了。下面是我自己在学习React历程的一些关键点，以及我的一些背景情况。
- 我已经写了18年的代码，其中13年是全职专业的老司机了；
- 其中6年时间都专注于Flash开发；
- 直到史蒂夫·乔布斯的公开信表示不支持Flash；
- 我刷过HTML，CSS和JS这几个技能点；
- 曾经在主流JavaScript框架的研究上纠结了很久，当时感觉它们把大量的逻辑都隐藏在了背后；
- 辞职开始外包生活，主要做原型；
- 看了很多ReactDemo；
- 2015年10月，正式开始React项目生涯并且爱上了它；
- 2016年1月，改了我在LinkedIn上的Title：React开发者。
接下来是我所总结的一些经验，希望能对你有所帮助。
改变React组件行为依赖于你传递的props，这是个很有用的功能。在项目初期就养成一个好的编程习惯对未来很有好处：创建一些通用组件，使其在其他地方也可以使用。
当你开始了项目以后，对于一个组件你可能会不断地扩展这个组件的使用外延。一段时间以后你会发现，你会疲于修复bug，在A场景下修复好以后，又发现在场景B和场景C下又发现了bug。
我的建议：如果一个组合组件导致了bug，那么把它分解成若干个简单组件，即便代码重复也值得。
只要你使用React，就一定会用到开源软件，不论是React核还是1000多个可用的NPM模块。如果你发现了库中有bug，那就提Issue上去。更好的情况是，如果你fix了一个bug，一定要提PullRequest把修复的代码整合进去，因为使用这个库并且遇到bug的并不只是你一个人，这样做会使整个生态变得更好。
我的建议：回馈社区，即便你只是修正了文档中的拼写错误也好。
我知道这并不是一个常见的场景，但是我就遇到过，当我开始一个外包项目并且开始build的时候，发现有一些依赖编译的包不存在。进而才发现实际上这个React是用于一个Backbone项目中的。在Backbone中实现React组件其实非常简单，使用Redux可以在这两个之间进行通信。它们之间的通信必须要通过Browserify或者Webpack编译到一起才可以。
我的建议：如果在一个现有的项目中应用React，首先用Browserify或者Webpack走一遍build过程比较好。
D3在数据可视化方面做的非常棒，但是如果你只是要做一些简单的数据可视化，那么渲染原生SVG就可以满足你的工作需求了。
我的建议：学习一些SVG基础，在你需要更复杂功能之前这就够了。Youtube的前端中心频道前几天刚好播放了关于SVG的节目，值得一看。
如果你要做的工作只是渲染，那么React和React-DOM就足够了。
Redux的处理很耗费时间和精力，它对于处理大项目中的多层UI很有用。但是如果你的项目很简单的话，那么通过传递props和callback就好了，不必要使用Redux。
我的建议：模板项目是非常有用的，但是如果你想保持项目精简的话，从React和React-DOM开始是一个很好的选择。
我没有办法精确地告诉你什么时候会看到帧速率显著下降，也许是30个元素的时候，也许是300个元素的时候。但是可以告诉以一些对你有帮助的经验。充分利用React的虚拟DOM，并且保证只在需要的时候进行渲染和重渲染。
就是说只渲染那些在视图窗口中可见的组件。
我的建议：在低配机器上进行测试，同时还要测试边界数据来看一下你的程序在受限的情况下表现如何。
如果你正在学习新库或者新框架，从模板项目开始是比较好的方法。如果你们公司有自己的模板就更好了。
但是不要认为模板项目可以解决所有问题。实际工作中你会发现，它所实现的根本就不是你想要的那样。如果你没有自己从头开始构建一个项目，那后面可能会出现很多问题。另外，如果你对一个模板项目的各种特征不是很了解的话，你很可能会重构一个它已经存在的功能。
我的建议：把模板项目用在它们最擅长的地方——快速启动项目。不要害怕重构它们，你要让它们按照你的意志去运作，另外，最好提前了解你所使用的模板项目的特性。
用Redux来build的时候，最好要限制组件的个数，同时要尽量保证actions/reducers的可复用性。
组件应该只依赖于自己的props。
Connected组件应该通过Redux来访问应用数据，并且应该只渲染自己的DOM和子组件。
容器充当一个演奏师的角色，取数据并且渲染组件。
我的建议：注意保持命名和功能的一致性。
我开发过各种各样的项目，经历过各种形式的代码检查。从一点代码检查都没有的项目，到甚至连一个悬空逗号都会拒绝提交的项目。
我想我们大多数人都会同意代码质量不仅仅是你用对了空格符和制表符。当打开一个文件时候，代码给你那种赏心悦目的感觉会让你写代码而舒服，而且你的注意力可以专注于你的代码逻辑。
代码检查也可以帮助你发现一些错误，比如常量分配和书写错误，甚至经典的“Undefinedisnotafunction”错误。
我的建议：拥抱你的团队所要求的代码审查规则吧。我在JS中使用ESLint，在Sass项目Atom中使用scss-lint。你也可以设置规则来方便转换，如果你要求很严格，不想让不好的代码提交上去的话，pre-push会执行一个npm脚本来做push前的检查。
有很多博文介绍如何安装普通应用，但是大多数都假设你是想要一个单页面应用，很少文章介绍如何在一个多页面Express应用中渲染单React组件。
我的建议：这种情况下，ReactDOMServer会成为你的朋友。你可以把组件都当成是页面片段，把它们传递给一个模板来渲染。
Saga是Redux中间件，基于ES6的生成器新特性。“生成器定义了可以保持自己state的迭代算法”。在实践中它和正常的JavaScript工作流是不一样的，因为在另一个基于Promise代码执行的时候，这个函数可以在执行过程中暂停。
我应该不是第一个，也不是最后一个说这话的人，Saga让我的大脑一团浆糊。刚学习Saga的时候一团乱麻，不过最终我还是征服了它。不过回头想想，如果我一开始就理解了生成器的话，可能事情发展会变的好一些。
我的建议：如果你是第一次使用Saga，并且团队中没人有相关的经验的话，你最好还是先理解Promise和Generator，会对你很有帮助。
上面这些是学习React以来我自己总结的一些经验。去年对我来讲是很不一样的一年，接触到了不同类型的项目，同时也学到了很多。很期待接下来的时间继续探索些新的事物。比如ReactNative。很高兴你能看完本文，希望能对你有所帮助。
如果你认为文章中还需要注意什么，或者添加什么，请让我知道。
我最近正在写一本《React.js小书》，对React.js感兴趣的童鞋