Skip to content

Latest commit

 

History

History
157 lines (81 loc) · 13.4 KB

File metadata and controls

157 lines (81 loc) · 13.4 KB

一、创建个性化开发生态系统

当人们听到反应时,他们会想到一个用于高效呈现用户界面的聚焦库。当人们听到框架时,他们会想到一个大型系统,其中可能包含一些有用的工具,但在其他方面则是一团臃肿的烂摊子。他们对框架的看法在很大程度上是正确的,但是说 React 不是框架有点误导。

如果你把 React 从盒子里拿出来,并试图用它进行任何有意义的开发,你会很快遇到麻烦。这是因为 React 不是作为一个整体框架分发的,而是一个由工具生态系统包围的核心库。

框架的优点是,您可以一次性安装核心库和支持的工具。缺点是每个项目都是不同的,你无法确定你需要什么工具,而你不需要什么工具。拥有一个工具生态系统的另一个好处是,它们可以彼此独立地进化;您不必等待整个框架的新版本,就可以获得项目使用的工具之一的增强。

本书的目的是向您展示如何最好地利用工具生态系统。在本章中,将通过学习以下内容向您介绍 React 工具的概念:

  • 不使用工具进行反应
  • 模具简介
  • 这本书中介绍的工具
  • 决定项目需要哪些工具

React 包含哪些内容

在我们深入讨论工具之前,让我们确保我们在相同的页面上讨论 React 是什么,以及安装包时实际附带了什么。运行 React web 应用需要两个核心 React 包。我们现在来看看这些,为您提供一些思考 React 工具的上下文。

比较渲染树的组件

React 堆芯的第一部分是名为react的包。这个包是我们在编写 React 组件时直接使用的接口。这是一个很小的 API,我们唯一真正使用它的时候是在我们创建带有状态的组件时,我们需要扩展Component类。

react包的幕后有很多事情。这是渲染树所在的位置,负责高效地渲染 UI 元素。渲染树的另一个名称是虚拟 DOM。其思想是,您只需编写 JSX 标记来描述要呈现的 UI 元素,而呈现树会处理所有其他内容:

在这个图中,您看到的是代码直接与之交互的组件,以及负责处理由更改状态的组件导致的呈现更改的呈现树。渲染树及其为您所做的一切是 React 的关键价值主张。

DOM 渲染目标

React 核心的第二部分是文档对象模型DOM本身。事实上,virtualdom 的名称来源于 React 在实际与 domapi 对话之前在 JavaScript 中创建 DOM 表示的思想。但是,渲染树是一个更好的名称,因为 React 正在基于 React 组件及其状态创建一个AST(简称抽象语法树)。这就是为什么同一个 React 库能够处理像 React Native 这样的项目。

react-dom包用于通过直接与浏览器 DOM API 通信,在浏览器中将渲染树转换为 DOM 元素。下面是前面的图,其中包含了react-dom

这是一个很好的架构,它意味着你可以用react-dom代替另一个渲染目标,而不需要太多的努力。如您所见,React 的核心层非常小。难怪它如此流行,我们可以用声明性代码创建用户界面,这些代码易于维护,而且效率很高,而我们只需付出很少的努力。记住这一点,让我们把注意力转移到使所有这些成为可能的工具上。

介绍工具?

工具不是唯一的反应工具。每个项目都有自己的一套工具来处理与核心技术相关的任务,因此您不必这样做。有了框架,大多数情况下工具都会被烘焙到项目中。使用 React 这样的库,您可以选择所需的工具,而不是那些在项目中不起作用的工具。

现在您知道了 React 的核心是什么,React 生态系统的其余部分是由什么组成的?

React 之外的辅助任务

对于很多人来说,框架膨胀是一个主要的障碍。它看起来膨胀的原因是因为它们有很多你可能永远不会使用的功能。React 能够很好地处理这个问题,因为它在核心库和其他任何东西(包括 React 开发所必需的东西)之间有着明确的区别。

我对 React 及其在周围生态系统中的定位方式进行了两次观察:

  • 部署依赖于简单库而不是包含所有电池的框架的应用更容易
  • 当您拥有的工具在大多数情况下都不碍事时,考虑应用开发就更容易了

换句话说,您不必使用大多数 React 工具,但其中一些工具非常有用。

任何给定的工具都是您正在使用的库的外部工具;记住这一点很重要。工具的存在是为了自动化一些东西,否则会从我们的生活中抽出更多的开发时间。生命太短暂了,我们无法手动完成可以为我们完成的事情。我再说一遍,对于那些软件比我们表现得更好的任务来说,生命太短了。如果您是 React 开发人员,请放心,因为有工具可用于您需要做但没有时间做的所有重要事情。

建筑工地类比

也许,认真对待工具的最终动机是思考如果没有我们作为专业人员所依赖的工具,生活会是什么样子。建筑业比软件更成熟,是一个很好的例子。

想象一下,你是一个团队的一员,负责建造一座房子,这是一项非常复杂的任务,有许多活动部件。现在,想想你必须处理的所有事情。让我们从材料本身开始。任何不需要在现场组装的东西都不是。当你在建房子的时候,很多部件都是部分组装的。例如,屋顶框架或混合水泥的部分在需要时显示。

然后是建设者在组装房屋时使用的实际工具,简单的螺丝刀、锤子和卷尺被认为是理所当然的。如果没有在场外创建组件的能力,或者没有使用日常建筑材料的工具,建筑寿命会是什么样子?这会使建造一座房子变得不可能吗?不。建造它的过程会变得非常昂贵和缓慢,以至于在完工之前可能会被取消吗?对

不幸的是,在软件世界中,我们才刚刚开始了解工具的重要性。我们拥有建造未来之家的所有材料和知识并不重要。如果我们没有正确的工具,它可能永远无法构建。

JSX 需要编译成 JavaScript

React 使用一种类似于 HTML 的特殊语法来声明组件。这个名为 JSX 的标记嵌入到组件 JavaScript 中,需要编译成 JavaScript,然后才能被浏览器使用。

最常见的方法是使用 Babel-a JavaScript 编译器和 JSX 插件:

诀窍是找到一种方法使编译步骤尽可能无缝。作为一名开发人员,您不需要关心 Babel 生成的 JavaScript 输出。

需要传输较新的 JavaScript 语言功能

与将 JSX 编译为 JavaScript 类似,更新的 JavaScript 语言功能需要编译成各地浏览器广泛支持的版本。事实上,一旦您了解了如何将 JSX 编译为 JavaScript,就可以使用相同的过程在不同版本的 JavaScript 之间进行传输:

您不必担心 JSX 或 JavaScript 编译的转换输出。这些活动更适合工具来处理,因此您可以专注于应用开发。

热模块加载以支持应用开发

web 应用开发的独特之处在于,它主要是加载到浏览器中的静态内容。浏览器加载 HTML,然后加载所有脚本,然后运行这些脚本直到完成。有一个长期运行的进程,它根据应用的状态不断刷新页面—所有内容都是通过网络进行的。

正如您可以想象的那样,在开发过程中,当您希望看到代码更改的结果时,这尤其令人讨厌。您不希望每次执行操作时都必须手动刷新页面。这就是热模块更换发挥作用的地方。本质上,HMR 是一种监听代码更改的工具,当它检测到代码更改时,会向浏览器发送新版本的模块:

即使使用 Webpack 之类的工具及其 HMR 组件,要使此设置正常工作也非常耗时且容易出错,即使对于简单的项目也是如此。谢天谢地,现在有一些工具对开发人员隐藏了这些设置细节。

自动运行单元测试

您知道需要为组件编写测试。并不是你不想写实际的测试;让他们能够奔跑是一件痛苦的事。Jest 单元测试工具简化了这一点,因为它知道在哪里可以找到测试并可以运行它们:

使用 Jest,我们有一个地方可以进行所有的单元测试,每个单元测试都依赖于他们正在测试的组件。这个工具知道在哪里找到这些测试以及如何运行它们。结果是,当我们需要时,我们可以得到很好的单元测试和代码覆盖率输出。除了实际编写测试之外,没有其他开销。

关于类型安全的思考

JavaScript 不是类型安全的语言。通过消除运行时错误的可能性,类型安全性可以极大地提高应用的质量。同样,我们可以使用工具来创建类型安全的应用。Flow 工具可以检查代码,查找类型注释,并在发现错误时通知您。

代码质量的 Linting

有一个有效的应用是一回事;拥有一个能够正常工作且具有可维护代码的应用是另一回事,它不会让人们的眼睛流血。实现可测量代码质量的最佳方法是采用标准,如 Airbnb(https://github.com/airbnb/javascript )。实施编码标准的最佳方法是使用一根过梁。对于 React 应用,首选的脱毛工具是 ESLint(https://eslint.org/ )。

隔离组件开发环境

React 开发人员最容易忽视的工具可能是 Storybook,它用于独立组件开发。在开发组件之前,您不会意识到这一点,但应用可能会遇到阻碍。有时,您只想查看组件本身的外观和行为:

使用像 Storybook 这样的工具,为组件提供一个独立的上下文,而不受其他组件的干扰是很简单的。

提供基于浏览器的调试环境

有时,查看单元测试输出和源代码不足以找出您遇到的问题。相反,您需要在与应用本身交互时看到发生了什么。在浏览器中,可以安装 React 工具,该工具可以轻松检查 React 组件,因为它们与呈现的 HTML 内容相关。

React 还具有一些内置的性能监视功能,可以扩展浏览器开发人员工具的功能。您可以使用它们在较低级别上检查和分析组件。

部署 React 应用

当您准备部署 React 应用时,它并不像生成并分发构建那样简单。事实上,如果您正在构建托管服务,您甚至可能根本不分发它。无论应用的最终用例是什么,除了 React 前端之外,可能还会有几个移动部件。越来越多地,将构成应用堆栈的主要进程容器化是首选方法:

为了像这样创建和部署 React 应用堆栈,您将依赖 Docker 之类的工具,尤其是当需要自动化项目的各种部署场景时。

选择正确的工具

如果上一节中的工具对于单个项目来说似乎有点太多,那么不要担心。试图同时利用所有可能的 React 工具总是一个错误。一次解决一个问题,从要点开始。随着项目的推进,添加可选工具以扩展工具集。

基本工具

有一些 React 工具是你无法离开的。例如,浏览器不理解 JSX 语法,因此需要将其编译为 JavaScript。在编写代码时,您需要对代码进行筛选,以确保不会遗漏基本错误,并且需要运行单元测试。如果你足够努力的话,你可能没有这些工具也能过得去。但这是一件你会花更多的精力不使用一个给定的工具,而不是简单地接受它。

作为一个起点,找到允许您取得进展的最少一组 React 工具。一旦你的进度明显减慢,是时候考虑引入额外的工具了。

可选工具

可选工具是您可能无法从中获得任何实际价值的东西。例如,在项目刚开始时使用 Flow 检查类型安全性或使用 Storybook 隔离组件开发可能不会带来巨大的好处。

要记住的关键是,任何 React 工具都是可选的,没有任何决策是永久性的。以后,您可以随时引入流程,如果独立组件开发不是您的事情,您也可以随时抛弃故事书。

总结

本章向您介绍了 React 生态系统中工具的概念。您了解到,React 的核心是一个简单的库,它取决于在现实世界中使用多个具有任何价值的工具。框架试图提供项目所需的所有工具。虽然方便,但框架用户的需求很难预测,可能会分散核心功能的注意力。

接下来,您了解到 React 中的工具可能是一个挑战,因为作为 React 开发人员,您要负责选择正确的工具并管理它们的配置。然后,您对工具有了一个概述,您将在本书的其余部分中更详细地了解该工具。最后,您了解到一些工具对于 React 开发至关重要,您需要立即设置它们。其他选项是可选的,在项目生命周期的后期出现实际需求之前,您可能不会开始使用它们。

在下一章中,您将使用创建 React 应用工具引导 React 项目。