有很多文章和博客包含有关如何以正确的方式做事的有用信息。最佳实践，良好的设计模式，良好的编码习惯，适当的状态使用，等等……
所以我决定把事情如何相反的方式，并期待不做事！
这篇文章将陈述不好的做法，并将它们组合成一个愉快的阅读。
使用 state 处理太多东西
虽然使用useState或创建的 ReactJS 状态useReducer很有用，但并非所有内容都应该放在其中。许多新开发人员都在为这个概念而挣扎。他们不知道何时该将某物放入该状态，何时该不该放入该状态。
一个例子是将数据存储在应该从状态中派生的状态中。假设您有一个状态，表示网店上的购物车已装满。不好的做法是在国家内部设定总价格。人们可以简单地计算来自状态的值。
出于这个特殊原因，存在简单的计算任务或变量。通常的想法是在您所在的州存储尽可能少的数据。在将数据放入状态之前，问问自己是否可以从其他存储的变量或状态中获取所需的数据。
不需要时使用 Redux
我只需要把这个永恒的 React 开发者的辩论放在这里。开发人员会问并说出这样的话：“我应该使用 Redux 还是应该使用 Context？”、“只使用 Context 而不是 Redux”或“Context 是 Redux 的良好替代品吗？”
有许多工具和机制可以部分完成 Redux 的功能。这简而言之解释了上述问题和陈述。
让我们尝试一劳永逸地解决这场争论。
Redux & Context
许多开发人员倾向于认为 Context 本身就是一个状态管理系统。这是不是！上下文是一种依赖注入机制。
在它里面你可以放任何你想要的东西，如果你以这种方式实现它，它可以成为一个状态管理系统。必须使用useState和/或useReducer钩子来管理其中的状态。这样，您就可以决定状态所在的位置，并处理如何更新它以及您希望在何处使用它。
上下文正是为了避免通过多层组件传递数据。如果您只需要解决这个问题，那么只需使用 Context。
Redux 和缓存如今，
大多数应用程序都需要某种类型的缓存来保存服务器状态。
如果我们坚持使用 REST API，那么有几个库可以为您进行缓存。例如React Query或 Vercel 的swr都在 REST API 方面做得很好。
如果我们使用更现代的 GraphQL 方法，使用Apollo Client缓存真的很容易。
如果缓存是您的应用程序中的唯一必需品，那么此时您的应用程序中不需要 Redux。
那么 Redux 有什么用呢？
Redux 是一个通用的状态管理工具。它同时有很多用例。最值得注意的是：缓存状态、UI 状态、客户端上的复杂数据管理、中间件等
。最终，这完全取决于您正在构建的应用程序试图解决的具体问题。通常，您只需要部分 Redux 功能（全局状态管理、缓存）。
在组件内部声明组件
由于多种原因，这非常糟糕：
- 代码变得非常耦合。内部组件变得依赖于父组件的范围。
- 内部组件几乎不可重复使用。您不能导出内部组件，您只能将它们作为道具传递到范围更远的地方，这并不理想。
- 表现。在每个父组件的渲染上，将重新创建内部组件的声明函数。
在初始状态下使用道具（在某些情况下）
请记住，对通用组件（例如来自官方 React 文档的计数器组件）使用初始状态是完全没问题的。更详细地说，这意味着将 props 设置为 state 以便使用非响应式 prop 初始化组件的状态。
在提供的示例之外，不应将初始反应状态设置为反应道具的值。为什么？因为除非你调用状态设置器，一个 setState 函数，否则该状态不会改变。如果上层的 props 发生变化，组件将获得更改后的 props，但是状态将保持与初始 props 值相同。
这个问题破坏了组件中使用的单一事实来源概念。这是一种不好的做法，应该避免。
使用索引作为键
您可以使用array.map方法在 React 中渲染多个项目。键必须是唯一的，以便 React 可以处理该元素或组件的正确跟踪。如果您要将索引用作键，则该键在某些情况下可能是重复的，应该避免这种情况。
想象一下，您将通过一系列项目来渲染.map并使用索引作为键。此外，想象一下添加到中间或从数组中间删除一个项目。Key 最终会和以前一样，React 会假设它是和以前一样的元素/组件。
这可能会导致不良影响，应避免。
频繁使用扩展运算符
扩展运算符的用例很棒。如果使用得当，它可以帮助我们减少代码并以更清晰的方式管理它。在声明可重用组件或创建重用数据的新数据对象时，甚至在将参数传递给函数时，扩展运算符都很好。
然而，很多时候，开发人员会犯错误，在 props 上使用扩展运算符并在组件上设置错误或不需要的 props。这可能会导致控制台中显示以下错误：
不使用 useEffect、useMemo 和 useCallback 依赖项
所述的 React 钩子引入了依赖关系的概念。这只是一组项目，当更改时，将导致挂钩更新。如果您还没有做过几次这样的事情，管理依赖项可能会有点棘手。Dependencies 数组应该由反映钩子的项目组成，并且不应该被大量这些项目挤满。
ESLint 静态分析有一个规则可以帮助我们在那些钩子中使用依赖项。
如果您打算useEffect在组件挂载时使用一次，则依赖项数组只能为空。
过早的优化
做优化通常是一件好事，但不应该对每一件小事都做。要查看记忆化的好处，需要使用像useMemooruseCallback和 even 之类的钩子PureComponents。开发人员需要非常专注并适当小心地实施记忆，否则可能会一一打破记忆。
下图一千字：
错误地声明 TypeScript 类型
我们大多数人都已经喜欢上了 TypeScript，没有它就不能再用 JS 进行开发了。此外，我们大多数人都知道称为any,never和 的关键字unknown。
Unknown 表示所有可能值的集合，任何值都可以分配给这种类型的变量。它是任何
Never的类型安全对应物，表示空集，这意味着不能为此类类型变量分配任何值。
大多数时候应该避免这些。这再怎么强调也不为过。开发人员往往对 TypeScript 感到沮丧，然后只需编写这些关键字之一就可以摆脱它。这是一种不好的做法，应该避免。
有使用这些关键字的地方，但几乎不应该这样做：
- 使用
never在位置存在不会或不应该是一个值。 unknown在有值的地方 使用 ，但它可能有任何类型。- 使用
any如果你真的需要一个不安全的逃生舱口。
结论
我们今天遇到了许多不好的模式，以及如何避免它们并使用正确的模式来代替。如果您学会避免这些不良模式，您作为编码员的生活将会轻松得多，并且您将避免许多错误和潜在的重构。
非常感谢您的阅读！
资源：
https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html
https://isamatov.com/react-derived-state/
https：//开头的changelog .com/posts/when-and-when-not-to-reach-for-redux
https://blog.logrocket.com/when-to-use-never-and-unknown-in-typescript-5e4d6c5799ad/
https： //levelup.gitconnected.com/react-best-practices-avoiding-bad-practices-fefe6062787d
