构建一套最佳的React 组件文件结构

前端修罗场出品与精选前沿的技术动态，跟进国内外技术发展，每天花费5分钟，扩展技术视野，成为技术达人！本期文章由前端晚自习带来的React组件文件结构将帮助大家构建架构体系。

为前端项目创建适当且可扩展的文件结构可能是具有挑战性的。在使用像React这样的非优化工具时，我们拥有很大的自由度。

通常，当我们讨论文件结构时，讨论重点是整个项目。但是，同样重要的（也是经常被忽视的）是如何最好地构造组件的问题。

包含在组件目录中的内容

组件是每个React应用程序的构建块。因此，它们本身可以被视为小型项目。组件应尽可能独立（但不能更多）。

典型的组件目录可能如下所示：

├── components
│   ├── Component
│   │   ├── SubComponent
│   │   │   ├── SubComponent.test.tsx
│   │   │   ├── index.tsx
│   │   ├──  Component.stories.tsx
│   │   ├──  Component.test.tsx
│   │   ├──  icon.svg
│   │   ├──  index.tsx
│   │   ├──  utils.ts
│   │   ├──  utils.test.ts

让我们对上面的结构进行分解一下：

index 主索引文件

该文件的默认导出是组件本身。此外，该索引还可以包括命名的出口。例如，如果我正在构建Menu组件，则希望能够像这样使用它：

import Menu, { MenuItem } from 'components/Menu'

const ComponentWithMenu = () => {
return (
<Menu>
<MenuItem />
<MenuItem />
</Menu>
    )
}

因此，在索引文件中，我需要导出Menu为默认导出，还需要将MenuItem子组件重新导出为命名导出。这样，以后我就可以从同一位置导入这两者。显式重新导出还有助于记录哪些是公开的（并打算由应用程序的其余部分使用）以及该组件的私有内容。

注意：有一个论点是，只有默认的导出应该是公共的，其余的应该保持私有。

Test 测试

为什么将测试放在这里而不是放在单独的tests目录中？两个字-代管！

属于一起的文件应该放在一起。如果您想象编辑或者删除组件的过程，此方法的好处将变得非常明显。当所有事物都集中在一个地方时，维护变得更加简单。

此外，测试通常用作文档。因此，将它们放在我们的组件旁边非常有意义。

Story

Storybook(storybook.js.org)是一款出色的工具，可用于独立开发组件。它使我们能够将我们的组件真正视为独立的微型项目。

出于上述所有相同的原因，将每个story及其相应的组件并置在一起很重要。

Styles 样式文件

使用CSS-in-JS时，可以直接在组件文件中创建样式化的组件。如果我们选择了CSS模块，则样式文件应与组件位于其目录中。

Assets 资源文件

图像，图标或其他特定于组件的资源文件应直接放置在组件目录中。再次托管！

Utils 工具类

工具类程序可以包括从辅助函数到自定义钩子的所有内容。如果愿意的话，我们可以将它们分为不同的类别（钩子，服务等），但是适用相同的基本原理。

我们应该确保所有utils都是特定于组件的，而不是应由应用程序其他部分重用的东西。utils的测试位于组件目录中。

Sub-components 子组件

子组件的结构与主组件非常相似。它们通常供主组件使用。

如果您打算在整个应用程序中使用它们（如MenuItem示例所示），则应将它们重新导出到主索引文件中。没有主要组件的子组件应该是不可能的。

如果是这种情况，则子组件本身应成为主组件。

子组件应具有自己的单元测试（需要时），样式和资源文件。大多数情况下，story仅保留给主组件。

保留在组件目录之外的内容

这是一个很好的规则：如果你曾经想使用除已从组件索引中显式导出的内容以外的其他内容，则明确表明此特定代码段应放置在其他位置。

让我给你举个例子：

让我们回到菜单组件。通常，我们希望如果用户在菜单外单击，它将关闭。为此，我们创建了一个自定义钩子useClickOutside并将其放置在utils中。

一段时间后，很明显，我们这次需要Dialog组件使用完全相同的行为。

我们想重用我们的钩子，但与此同时，它不再是特定于组件的。我们应该将其从Menu组件中取出，然后将其放在更高的位置，也许放在我们的常规utils文件夹中。

很多时候，如果一段代码执行相似（但不完全相同）的操作，最好首先复制一些功能，并且仅在对用例有足够的信心时才创建抽象。

总结

组件结构对于React体系结构至关重要。弄错了可能对项目的可伸缩性和可维护性产生长期影响。这就是为什么重要的是要指出我上面提出的只是一个模板。

尽管我发现这种结构适用于各种场景，但是每个React应用程序都是唯一的，或者至少具有其特质。通用指南不能取代对项目细节的批判性思考并做出相应的决策。