我很难理解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(｛/状态对象/｝(将调用组件Car的this.setState
与Redux或Context API相比，我没有那么头疼。问题是：这是一种糟糕的做法吗？如果雇主在我的代码中看到这一点，我的机会会减少吗？如果是，为什么这是一种糟糕的做法？
您通常不应该创建一个扩展React.Component的类，而您不打算直接将其用作组件。虽然这些是"；类"；，它们不应而用于继承。类组件只是用于React组件的语法，但您不应该真正使用所有"类"组件；类特征"；。
此外，为了确保您意识到这一点：在这一点上，类组件几乎被认为是遗留的。大多数生态系统都在转向钩子，在一两年内，您可能会在寻找支持遗留样式类组件的新库时遇到问题，更不用说使用"钩子"了；类特征"；在即将推出的React 18中，类属性将变得更加棘手。
总之：一般来说，你可以做这样的事情(创建你自己的解决方案，而不是你想要的继承模式(。但你可能应该更好地看看现有的图书馆，这样你就不必学习所有的"；经验教训"；现有图书馆的艰难之路。
Redux的替代品是MobX、Recoil、XState、Valtio或Zustand，所有这些都会给你一个不同的心理模型
另一方面，上下文不适用于状态处理，因为它需要大量手动优化，甚至存在当前React无法解决的性能问题。无论无数教程试图告诉你什么，它都不是为国家而生的。
但你也可以给Redux第二次机会。当你使用类组件时，很有可能你也一直在学习过时的Redux课程——在过去几年里，现代的Redux变得更加简单。如果你的课程显示减速器中的switch (action.type) { case...或connect和mapStateToProps，那么这是一个过时的教程，根本不能反映现代Redux。如果你想了解现代Redux，最好的方法是遵循官方教程：https://redux.js.org/tutorials/essentials/part-1-overview-concepts