作为 React 承包商的 11 条经验教训
作为 React 承包商的 11 条经验教训
原文：https://medium.com/hackernoon/11-lessons-learned-as-a-react-contractor-f515cd0491cf
我不知道我在找它，但是当我找到它的时候，我突然明白了。
以下是我反应之旅的要点版本
- 我已经写了 18 年的代码，专业地写了大约 13 年
- 其中 6 年，我是一名专注的 Flash 开发人员
- 史蒂夫·乔布斯的公开信之后，所有的闪光点都消失了
- 记得我可以写 HTML，CSS 和 JS，重温这些技能
- 我和主流的 Javascript 框架斗争了一段时间，他们感觉隐藏了太多的逻辑，在 NPM 之前的世界里，他们就像是巨大而脆弱的野兽
- 离开我的全职工作开始承包，主要是原型制作
- 看了几个的会议演示反应
- 2015 年 10 月，我虚张声势地加入了 React 项目，并爱上了它
- 2016 年 1 月，我把 LinkedIn 上的职称换成了 React developer……
这些是我学到的一些东西
1:多个简单的组件比一个高度可定制的组件更好
能够根据你传递给它的道具来改变一个 React 组件的行为是它的一个重要特性。然而，在一个项目的早期，很容易养成一种习惯，即构建一些真正通用的、可以在很多地方使用的组件。
一旦你进入了项目的核心，你开始充实你的组件需要如何被使用的所有边缘情况，你会发现你自己在场景 X 中使用组件 A 的地方追着你的尾巴修复错误，却发现它在场景 Y 和 z 中创造了更多的错误。
我的建议:如果一个可组合的组件导致了错误，把它分解成更简单的一次性组件，即使你在重复代码。
2:如果你在库中发现了 bug，一定要提出问题或请求
如果不使用开源软件，你就无法使用 React，无论是核心的 React 项目还是 NPM 上可用的 1000 个模块中的任何一个。如果你发现了一个 bug，在项目的回购中提出一个问题——如果你修复了一个 bug，那就更好了，但是提出一个 Pull 请求并合并修复。很可能你不是唯一一个想要修复这个 bug 的人。
我的建议:回馈社会，即使只是修改文档中的错别字。
3:首先实现一个构建过程，然后做出反应
我知道这听起来像是一个不太可能的场景，但是我开始了一个构建 React 组件的合同，却发现它所使用的主干项目正在被编译而没有被编译依赖项。在 Backbone 中实现 React 组件相当简单，使用 Redux，您甚至可以在两者之间进行通信。然而，它们只有在与 Browserify 或 Webpack 一起编译时才能通信。
我的建议:如果你在一个现有的项目中实现 React，首先将你的构建过程迁移到 Browserify 或者 Webpack 。
4:用于简单数据可视化的原始 SVG >= D3
D3 对于数据可视化来说很棒，但是如果你构建的东西很简单，也许只需要渲染一些原始的 SVG 就可以完成工作。
我的建议:学习一些 SVG 基础知识，你就可以在依赖其他任何东西之前把它推进相当长的一段路。前端中心 Youtube 频道前几天刚好在 inline SVG 上掉了一个很棒的视频，你应该去看看！
5:当你只有两周时间的时候，保持精简
如果你所做的只是渲染，那么你所需要的就是反应和随机反应。
没人有时间听这些废话！Redux 非常适合在具有多级 UI 的大型项目中处理状态，如果你正在构建的东西相当简单，你可以只传递道具和回调。如果项目最终增长，你会知道什么时候开始实现 Redux，并且在那时添加它应该是相当容易的。
我的建议:样板项目可能是有用的，但是如果你想保持精简，从 React-DOM 开始，然后从那里开始。
6:仅仅依靠 CSS 动画来移动大量元素会很慢
我不能准确地告诉你什么时候你会看到帧速率的显著下降，也许是 30 个元素或 300 个，但你可以做些事情来帮助。利用 React 的虚拟 DOM，并确保只渲染或重新渲染真正需要的组件。
这可能意味着，计算哪些组件在视口中可见，并且只渲染那些组件。
我的建议:在较低规格的机器上进行测试，但也要用极端数据进行测试，看看当它们被推到极限时运行得如何。
7:样板文件是一个很好的起点，但是…
如果你想学习一个库或框架，样板工程是一个很好的起点。如果你的公司有自己的样板文件，那太好了！
然而，不要被愚弄，以为样板文件是一切的解决方案。最终你会意识到它并不能完全满足你的需求，如果你没有从头开始构建这个项目，它会令人望而生畏。此外，如果它是一个大型的高度特色的样板文件，您可能会意外地重新构建它已经拥有的功能。
我的建议:只使用他们擅长的样板——快速启动项目。不要害怕打破它们，扭曲它们，并随意滥用它们。
8:维护可预测的组件、连接组件和容器模式
当使用 Redux 构建时，最好限制可以访问存储的组件的数量，以确保尽可能多地重用 actions/reducer。
组件要哑，只能靠自己的道具。
连接组件通过 Redux 访问 app 数据，有一些复杂的业务逻辑，但是渲染自己的 DOM 和一些子组件。
容器是瘦的编写器，接受数据，只呈现其他组件。
我的建议是:保持命名和连通性的一致性
9:严格的林挺是福也是祸
我参与过不同的项目，涉及林挺的方方面面，从完全没有林挺到如果你漏掉一个逗号就会拒绝你推送的 git 钩子。
我想我们都同意代码质量不仅仅是确保你使用了正确数量的制表符或空格。打开一个看起来很漂亮的文件会有一些乐趣，它给你的强迫症一个放松的机会，你可以专注于写代码。
林挺还帮助捕捉错误，如重新分配常量和拼写错误，甚至是经典的“未定义不是一个函数”。
我的建议:接受你的团队所能忍受的最严格的林挺规则。我对 JS 使用 ESLint，对 Sass 使用 Atom 中的 scss-lint。为了使转换更容易，您可以关闭某些规则。如果你想成为硬核并阻止人们推送坏代码，预推送将在预推送 git 挂钩期间运行 NPM 脚本。
10:在现有的 Express 项目中改装通用 React 渲染是可行的…
…但是你可能会因为试图这么做而长出几根白头发！
关于如何设置一个通用的应用程序，有相当多的博客文章，但大多数都假设你想要一个单页面应用程序，很少展示如何将单个 React 组件渲染到现有的多页面 Express 应用程序中。
我的建议 : ReactDOMServer 是你的朋友，就想象一下组件是页面片段，你只是把它们传递给模板进行渲染。
学习传奇故事可能会融化你的大脑
Sagas 是一个基于生成器的 Redux 中间件，这是 ES6 的新特性。“生成器”通过编写一个能够保持自身状态的函数来定义迭代算法这在实践中不同于 Javascript 的正常流程，因为在运行另一个基于 Promise 的代码块时，函数可以在其执行期间暂停。
我可能不是第一个也不是最后一个这么说的人，传奇故事融化了我的大脑！
一旦我设法让他们工作，我的大脑重新固化，我开始写一些传奇的测试，我的大脑再次融化。
我最终还是屈从了他们的意愿，为这个项目写了一整套测试。如果我一开始就充分了解发电机，事情可能会有所不同。
我的建议:如果你第一次使用 Sagas，而且项目中没有人能解释它们是如何工作的，那么在你深入研究之前，确保你对承诺和发生器有深刻的理解
这只是我今年学到的一些重要的东西。对我来说，这是令人兴奋的一年，参与了许多不同类型的项目，同时也学到了很多东西。
展望 2017 年，我的清单上有几件事情要探索，首先是我开始的 React Native side 项目，我一直想再看看，另一个是风格的组件。
如果你想查看我在 LinkedIn 上的简介，你可以，如果你喜欢的话，我也在 Twitter 上。
2016 快乐！
