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