javascript - 构建自己的状态管理器而不是使用 Redux 或 Context API 是一种不好的做法吗？

Question

我正在努力理解 Redux 或使用 Context API，所以我构建了这个简单的类:

import React from "react";

export default class X extends React.Component {
  constructor() {
    super();
    SM["set" + this.constructor.name] = function (obj) {
      this.setState(obj);
    }.bind(this);
  }
}

因此，如果我有一个组件(例如 )，其状态需要由其他组件设置，它将扩展类 X 并将其 setState 函数存储在名为 SM(状态管理器)的全局对象中。所以使用 SM.setCar({/state object/}) 会调用组件 Car 的 this.setState。
与 Redux 或 Context API 相比，我的头痛要少得多。
问题是:这是一种不好的做法吗？如果雇主在我的代码中看到这一点，我的机会会减少吗？
如果是，为什么这是一个不好的做法？

Answer 1

通常，您不应该创建扩展 React.Component 的类。您不打算直接用作组件。
虽然这些是“类”，但它们不应该用于继承。
类组件只是用于 React 组件的一种语法，但您不应该真正使用所有“类功能”。
此外，只是为了确保您意识到这一点:在这一点上，类组件几乎被认为是遗留的。大多数生态系统正在转向 Hook ，在一两年内，您可能会在寻找支持遗留样式类组件的新库时遇到问题，更不用说使用类属性等“类特性”在即将到来的情况下会变得更加困难 react 18.
总而言之:通常，您可以做这样的事情(创建您自己的解决方案，而不是您想要的继承模式)。但是您可能最好看看现有的库，这样您就不必自己艰难地学习现有库的所有“经验教训”。
Redux 的替代品是 MobX、Recoil、XState、Valtio 或 Zustand，所有这些都为您提供了不同的心智模型供您使用。
另一方面，Context 不适合状态处理，因为它需要大量手动优化，即使这样也存在当前 React 无法解决的性能问题。无论无数教程试图告诉您什么，它都不是为状态而制作的。
但是你也可以给 Redux 一次机会。当您使用类组件时，很有可能您也一直在学习相当过时的 Redux 类(class) - 在过去几年中，现代 Redux 变得更加简单。如果您的类(class)显示 switch (action.type) { case...在 reducer 或 connect和 mapStateToProps ，这是一个过时的教程，根本没有反射(reflect)现代 Redux。
如果你想看看现代 Redux，最好的方法是遵循官方教程:https://redux.js.org/tutorials/essentials/part-1-overview-concepts