React最佳实践 – 2022年编写更好的React代码的技巧

🌠 本文非原创，为原文的中文翻译版

📖 原文地址：https://www.freecodecamp.org/news/best-practices-for-react/

React 开发者面临的三大挑战

⚙️ 可维护性

这与可复用性息息相关。在应用程序和组件非常轻量的时候，它们很容易维护。但是，一旦需求开始增长，组件就会变得非常复杂，因此维护性较差。

我经常看到一个有许多不同情况代表不同结果的组件。JSX 充满条件渲染（三元运算符和简单&&运算符），根据条件添加 class names ，或者该组件使用巨大的Switch语句。有许多 props 和 state，每个都会造成不同的结果。

在我看来，这些技术本身并没有错。但是我认为，当组件开始变得较低的可维护以及这些技术变得过度使用时，每个人都应该对自己产生一种感觉。我们将在本文后面学习如何更好地控制这种情况。

问题（我也为此感到内疚）是组件越复杂、结果越不同（多态性），它就越难维护。

老实说，根本原因往往是懒惰、经验不足或时间压力，无法适当地重构组件，使其更易于维护和更整洁。

我看到的另一个关键因素是没有测试或测试很少。我知道，测试不是一个很多开发者喜爱的工作类型，但从长远来看，这确实可以帮助你。测试本身不会是这篇文章的主要话题，所以请留意我关于它的另一篇博客文章。

🧠 扎实理解 React

开发人员出现问题的另一个根本原因是对 React 如何在底层工作的基本理解不足。我也曾经这样。

我见过很多人在没有坚实基础的情况下，过快地进入中级或高级概念。但这并不是 React 独有的。这是编程中的一个常见问题。

对 React 没有扎实的理解也会给作为开发人员的您带来问题。我记得当我想使用不同的组件生命周期，但不知道如何实际使用它们时，我感到头疼。所以我不得不后退几步，深入探讨这个话题。

因为我认为这是最重要的事情之一，所以我在下面的博客文章中专门用了整整一章来介绍它。

📈 可扩展性

这项挑战与可维护性息息相关。它不仅针对 React，而是通常适用于软件开发中。

我了解到，制作优秀的软件不仅仅是关于 UX（用户体验）、干净的代码模式或聪明的架构。对我来说，软件的质量也会随着它的扩展能力而上升或下降。

对我来说，有很多东西可以提高软件的可扩展性。你将在这篇文章中学习我最重要的技巧。

我认为，当您在设计组件和组织项目结构时考虑到可维护性和可扩展性的话，您不太可能最终出现需要进行重大重构的混乱代码。

好了，现在让我们深入了解一些学习 React 的最佳实践。

了解 React 的基础

正如我们在上面简要讨论的那样，表明了基础不仅与学习 React 有关，也与其他技术或编程语言有关。你不能在沙质地基上建造摩天大楼，却期望它坚固。

这对你们中的许多人来说可能是显而易见的，但我见过一些开发人员在没有真正理解基础知识的情况下就跳到了 React 的中级或高级概念中。

一般来说，Javascript 也是如此。我坚信，如果你在 Vanilla Javascript（指原生 JS）方面没有坚实的基础，那么学习 React 是没有意义的。

所以，如果这听起来很熟悉，并且你正在考虑学习 React，但对 Vanilla Javascript 还不太熟悉，那么先花点时间加强 Javascript。这将在未来为你节省很多头痛和时间。

如果你想复习的话，这是一个有用的指南：top JavaScript concepts you need to know before diving into React

但对我来说，仅仅了解基本知识是不够的，去了解 React 的底层原理是强制性的。如果你想成为一名优秀的 React 开发人员（我认为你是这样做的，因为你正在阅读这篇文章），你必须知道你正在使用的工具。这对作为开发人员的你和你的客户都是有益的。

当然，你不可能无所不知，也不应该在这个话题上给自己施加压力。当你遇到实际问题并建立更多的项目时，你会学到越来越多的东西。但有了扎实的知识，你从一开始就全副武装。

好吧，这很有道理。但你可能想知道，为了在 React 中打下坚实的基础，你到底需要知道什么？

作为最低要求，您应该理解在官方的 React 文档中的主要概念章节。

你应该非常熟悉的另一章是关于Hooks的那一章，因为它们已经成为一种惯例，并且被广泛使用，尤其是在第三方 React 包中。

当然，你可能会更频繁地使用一些，比如useState和useEffect，但理解其他的，比如useMemo、useCallback或useRef也是必不可少的。

还有另一章叫“高级指南”，我一开始并不认为这是强制性的，但我强烈建议您在 React 之旅中掌握这些概念。

和往常一样，当你已经有了一些实践经验时，通常更容易理解高级话题。但你越早了解这些事情越好。

当然，你不应该局限于只关注 React 文档。通过一门涵盖这些基础知识的在线课程，观看教程或阅读其他博客文章，也是打下坚实基础的一部分。所以，测试一下什么最适合你。

如果我不得不选择至少最重要的概念来了解，我会建议：

什么是“状态”
类组件和函数式组件的区别
什么是组件重新渲染，它们是如何工作的？
如何触发重新渲染？
不同的组件生命周期以及如何与它们交互
Virtual DOM
CSR（客户端渲染）和 SSR（服务器端渲染）一般来说在 React 中的优势
受控组件和非受控组件
状态提升
至少一种全局状态管理技术（Context API、Redux/Toolkit、Recoil）
组件模式（尤其是如何选择正确的模式）

学习如何构建整洁、高性能和可维护的 React 组件

我知道——这是每个程序员的梦想（或者至少我希望是这样）。
对我来说，这种能力将好的程序员与出色的程序员区分开来。有趣的是，它从来没有真正完成，因为总会有一些需要学习和改进的东西。

遵循这些最佳实践不仅会让你，也会让你的队友更容易做到这点。我见过一些创建了风格指南的开发团队，他们定义了如何编写代码的重要基石。在我看来这是个好主意。

其中一部分是：

使用函数式组件（例如箭头函数）
不要使用内联样式
保持适当的导入结构（第三方导入优先 –> 内部导入在下面）
在提交之前格式化你的代码

等等。

当然，你可以做到非常详细。这取决你的团队。我个人不喜欢十分详细的风格指南，因为我认为作为一名熟练的开发者，你应该保持一些自由，不应该受太多限制。

但是，一般来说，样式指南是一个描述和保持最佳实践的好方法，并确保您的团队在有关某些重要部分时保持一致。我认为这会大大增加团队合作和产出。

让我们来看看创建干净、高性能和可维护的组件的最佳实践是什么。让自己感到舒适，找点东西做笔记，然后享受吧！

📁 创建合适的文件夹结构

在 React 应用程序中组织文件和文件夹对于可维护性和可扩展性是十分必要的。

良好的文件夹结构取决于您的应用程序和团队的大小。因此，这并没有一个普遍的答案。尤其是因为这是一个非常固执己见的话题，也取决于个人喜好。

But over the time, some best practices for different sizes of an application have evolved.

This great blog post goes through five different application sizes and introduces good ideas of how to organize your files and folders. Having this in mind when planning or starting your application can make a huge difference on the long run.

Don’t over-engineer it, but try your best maintain a proper structure that is best suited for your current application and your team size.

👇 Maintain a structured import order

If you’ve already got some experience in React, you might have seen files that are bloated with a lot of import statements. They might also be mixed up with external imports from third-party packages and internal imports like other components, util functions, styles and many more.

Real World Example (cut):

import React, { useState, useEffect, useCallback } from "react";
import Typography from "@material-ui/core/Typography";
import Divider from "@material-ui/core/Divider";
import Title from "../components/Title";
import Navigation from "../components/Navigation";
import DialogActions from "@material-ui/core/DialogActions"
import { getServiceURL } from '../../utils/getServiceURL";
import Grid from "@material-ui/core/Grid";
import Paragraph from "../components/Paragprah";
import { sectionTitleEnum } from "../../constants";
import { useSelector, useDispatch } from "react-redux";
import Box from "@material-ui/core/Box";
import axios from 'axios';
import { DatePicker } from "@material-ui/pickers";
import { Formik } from "formik";
import CustomButton from "../components/CustomButton";
...

In reality the imports span over 55 lines.

You probably recognize the deal here. It’s difficult to distinguish what are all the third-party and the local (internal) imports. They are not grouped and seem to be all over the place.

Better Version:

import React, { useState, useEffect, useCallback } from "react";
import { useSelector, useDispatch } from "react-redux";
import { Formik } from "formik";
import axios from 'axios';
import Typography from "@material-ui/core/Typography";
import Divider from "@material-ui/core/Divider";
import Box from "@material-ui/core/Box";
import DialogActions from "@material-ui/core/DialogActions";
import Grid from "@material-ui/core/Grid";
import { DatePicker } from "@material-ui/pickers";

import { getServiceURL } from '../../utils/getServiceURL";
import { sectionTitleEnum } from "../../constants";
import CustomButton from "../components/CustomButton";
import Title from "../components/Title";
import Navigation from "../components/Navigation";
import Paragraph from "../components/Paragraph";
...

The structure is clearer and it’s very easy to distinguish where the external and internal imports are. Of course you can optimize it more if you are using more named imports (if that’s possible! :) ). That allows you to import all the components that are coming from material-ui all on one line.

I’ve seen other developers who like to split the import structure up in three different parts:

Built-In (like ‘react’) –> External (third-party node modules) –> Internal.

You can manage it every time by yourself or let a linter do the job. Here’s a great article about how to configure your linter for your React app to maintain a proper import structure.

React最佳实践（未完整，持续更新）