[译] 项目何时须要 React 框架呢？

• 原文地址：When Does a Project Need React?
• 原文做者：CHRIS COYIER
• 译文出自：掘金翻译计划
• 译者：龙骑将杨影枫
• 校对者：Guangyuan (Charlie) Yang、薛定谔的猫

项目何时须要 React 框架呢？

你知道何时项目须要 HTML 和 CSS，由于这是项目的基础。何时用 JavaScript 也很清楚：当你须要只有它能提供的交互功能的时候。过去咱们何时应该用代码库也很清楚：咱们须要 jQuery 来帮助咱们简化 DOM 操做，调用 Ajax，处理浏览器兼容问题；咱们须要 Underscore 提供 JavaScript 没有的帮助函数（ helper functions ）。

可是随着对这些代码库的需求逐渐消失，咱们看到不少新兴框架的大幅增加。我认为，就不那么容易肯定什么时候须要它们了。好比说，咱们什么状况下须要 React 框架？

在众多的 JavaScript 框架中 —— Vue、Ember、Svelte ... 无论哪个，我想以 React 框架为例子来探讨它适合什么项目。我明白这些框架并不彻底相同，可是使用它们的时机应该是有一些共性的。

这是个人建议。

✅ 当项目中有大量的状态的时候

即使“状态（state）”这个词也没法彻底准确的表达个人意思。想象一下这些状况：

• 导航栏的哪一个栏目正处于激活状态
• 一个按钮是否被禁用
• 输入框的值
• 哪个下拉框是弹出的状态
• 什么时候加载某个区域
• 登录的用户如何进行权限控制
• 用户编写的文章是已发布状态仍是草稿状态

“业务逻辑” —— 咱们常常处理的这类东西。状态也可能和内容直接相关：

• 一篇文章中全部的评论，以及零零碎碎的组成它们的东西。
• 当前正在查看的文章，以及该文章的一些属性
• 一系列相关的文章，以及这些文章的属性
• 一份做者列表
• 一份记录用户近期操做的活动日志

React 框架并无帮助你组织这些状态，它只是说：我知道你须要处理状态的问题，因此咱们不如把它设为 state 属性，经过编程的方式进行读写。

在有 React 框架以前，咱们也许考虑过状态的定义，可是大部分时候并无把它看成一个直接的概念去管理。

也许你据说过这个短语“单一数据源”？不少时候咱们把 DOM 做为咱们的单一数据源。好比说，你须要知道是否能够提交某个表单了。也许你会用 $(".form input[type='submit']).is(":disabled") 去检查一下，由于全部影响表单是否可提交的业务逻辑最终都会改变按钮的 disable 属性。因此按钮变成了你的 app 事实上的数据源。

或者说，你须要知道某篇文章的第一个评论者的名字，也许你会这样写 $(".comments > ul > li:first > h3.comment-author).text()，由于 DOM 是你惟一能够得到这些信息的地方。

React 框架这样告诉咱们：

1. 咱们把这些全部的东西都想像成状态（state）。

2. 我会为你作好一件事：把状态转换为一串 JSON 对象，这样的话处理起来很容易，也许你的服务端能够处理的很漂亮。

3. 更棒的是：你能够用这些状态（state）直接构建 HTML ，你根本不须要直接操做 DOM，我都替你处理了（也许比你亲自处理的要更快更好）。

✅ 对抗面条式代码 （Spaghetti）

这和咱们刚才讨论过的状态有很是大的关系。

“面条式”代码，指的是代码的组织结构已经脱离你的掌控。再想象一下，假设有这么一个表单，它有一些专门处理表单内输入框的业务逻辑。该表单内有这么一个数字输入框，当这个输入框的值改变的时候，在旁边显示根据该值进行某些计算后的结果。这个表单能够被提交至服务端，所以也须要合法性检查，而也许合法性检查的代码位于其余地方的验证库中。也许在肯定某处的 JavaScript 代码所有加载完以前，你还须要禁用此表单，而这个逻辑也在别的地方。也许当表单提交后，你还须要处理一些返回值。没有什么特别让人意外的功能，可是凑在一块儿就很容易让人蒙圈。若是这个项目由一个新的开发人员接手，当他看到这个表单时如何能捋清这些逻辑呢？

React 框架鼓励把逻辑封装进组件。因此这个表单要么本身是一个组件，要么由其余的小组件组成。每个组件只处理与本身直接相关的逻辑。

React 框架说：嗯，你不会直接看到 DOM 的变化，由于 DOM 是个人，你没法直接操做它。为何你不把这些东西想象成状态的一部分，当须要的时候就改变状态（state）。我会处理其余的事情，从新渲染须要被渲染的界面。

应该说，只有 React 框架还不足以解决面条式代码。由于状态也可能出如今各个奇怪的地方，或者状态起的名字很糟糕，或者用莫名其妙的方式调用。

以我有限的经验来看，Redux 库才能真正解决面条式代码的问题。Redux 说：我会处理全部重要的状态，都是全局的，不是组件依赖的。我才是惟一的数据源。若是你须要改变状态，就要采用特定的仪式（我据说它是这么叫的，并且我喜欢这么叫）。经过 reducers 和被分发的（dispatched） actions，全部的改变都会遵循这种仪式。

若是你准备在项目中加入 Redux（或者 Redux 的变种），那么你就能够和硬编码说再见了。经过加入 Redux 框架，组件会变的高内聚，也很容易理清整个需求的逻辑走向了。

✅ 要管理大量的DOM

手动处理 DOM 多是引发面条式代码的最大缘由。

1. 在这里插入一段 HTML ！

2. 在这里把某些东西分离出去！

3. 监听特定区域的特定事件（event）！

4. 在这里绑定一个新事件！

5. 又来了新内容。再次插入到 HTML 里，确保它绑定了正确的事件！

此类事情能够发生在一个 app 的任何地方、任什么时候间，这就形成了面条式代码。手动管理是不靠谱的，由于这么作的话又变成 DOM 数据源了。很难准确的知道某个给定的元素发生了什么，因此每一个人只好直接查询 DOM ，作他们必须作的事情，顺便向上帝祈祷他们这么作没干扰到别人。

React 框架说：你不须要直接操做 DOM 。我用虚拟 DOM 来处理真实的 DOM。若是你想要操做 DOM，能够直接在虚拟 DOM 上操做。经过这种方式，全部的逻辑就有迹可循了。

管理复杂的 DOM 是另外一件适合 React 框架的事情。想象有一个聊天软件，当数据库接收到其余聊天者传递来的新聊天信息时，在聊天窗口里应该显示这些新的信息。不然你只能本身给本身聊天了！或者当聊天页面第一次被加载的时候，能够从本地数据库里找出几条旧信息显示出来，这样你马上有东西能够看了。好比说这个推特例子。

❌ 只是由于，React 框架是目前最火的框架。

学习新东西是很酷的，因此学习吧！

为了知足用户的需求而构建项目则须要更谨慎一点。

举个例子，一个博客也许没什么复杂的逻辑，一点也不符合应该使用 React 框架的状况。因此若是不是很适合的话，那么也许就是很不适合 React 框架。由于这么作引入了复杂的技术，依赖了不少根本没用到的东西。

在彻底适合和彻底不适合之间，若是这个博客是一个 SPA （“单页面应用”，不须要浏览器刷新），经过 headless CMS 获取数据构建该博客，而且具备出色的服务端渲染...好吧，也许又是 React 框架的领域。

若是是 web app CMS 建立的这种博客？也许用 React 是一个好选择，由于它也有一大堆的状态。

❌ 我就是喜欢 JavaScript ，就是想用它来编写任何东西。

我常常安利周围的人：学习 JavaScript。由于 JavaScript 的知识太丰富了。它能作不少不少的事情，也有不少的工做机会，因此好好学习 JavaScript 永远不会过期。

只有在最近的网络技术历史里，Javascript 才能够作全部的事情。你经过 Node.js 构建服务端，也有不少项目能够经过 JavaScript 处理 CSS。如今经过 React 框架，你还能够在 JavaScript 里写 HTML。

万物归于 JavaScript！JavaScript 万岁！

React 确实碉堡了，可是你能够用 React 并不意味着你必须用 React 。并非全部的项目都必须使用它 ，并且事实上，有至关一部分有可能压根不须要它。

☯️ 这就是我所知道的。

（是或者否均可以找到合适的图标来表达，可是想表达也许的意思就比较复杂）（译者注： 指做者此处用太极的图标表示也许的意思。）

你在学习，太好了。每一个人都在学习，因此坚持学习吧。你知道的越多，你越知道该用什么技术更好。

可是不少时候你只能以现有的技术来构建项目，因此我也不会反复强调这一点。

☯️ 这就是工做。

在给定的任何项目中，不是每一个人均可以由有权利决定应该底用什么技术。但愿随着时间的增加，你能够更大层度上的影响决策。Eden 说她花了两年的时间研究 Ember，由于这就是她的工做。没有任何冒犯的意思，可是拿人钱财就得替人消灾。Ember 也许比较适合这些项目。

• 相关译文：哪些项目须要 React？都须要！ 译者 sun

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、React、前端、后端、产品、设计 等领域，想要查看更多优质译文请持续关注 掘金翻译计划。