Question

Redux可能是整个应用程序状态的数据存储，可促进可伸缩性……众所周知，实际上并非如此。开发人员通常将其称为“过度设计” ，“繁琐” ，实际上与促进可伸缩性相反。许多开发人员试图提出替代方案，Context API，顶层的AppState类等。

开发人员错过了重点吗？在任何领域，尤其是CS领域，良好设计的基本宗旨是KISS。

保持简单，愚蠢！

让我感到震惊的是，开发人员错过了这一点。为了简化数据存储过程，所有需要的是一个“指针” （在C ++中将被称为）。您不需要Context API，Redux或任何其他麻烦的库，这些库所引起的问题超出了解决的范围。 React是一个很棒的库，由于设计麻烦的不必要的库来解决实际上不存在的问题，因此它失去了吸引力。

因此，在React Apps上下文中，“ pointer” 意味着只需向每个类的构造函数添加一行代码，以指向其“ this” 上下文，存储在外部对象中。为了保持React的命名法，我将此方法称为Atomic。什么是原子？它是一个只有一行代码的外部模块。

Atomic = {};

然后，在每个React类的构造函数中，添加一行代码（加上Atomic import语句）。

例如：

class MyComponent extends React.Component {
constructor(props){
    super(props);
    this.state = {x:"etc"};
}
//simply add the following line.
Atomic.MyComponent = () => this; 
}

现在，您只需调用Atomic指针，就可以从任何其他React类或实际上是任何外部模块（例如自定义数据存储区）访问任何React类的任何状态或函数。

如果需要，请在本地使用状态！将州集中在一个地方，并使用外部商店！只需几行代码即可完成所有操作。就我个人而言，我认为应按预期的方式使用react-状态存储在本地-但是现在，当组件需要相互交谈时，没有访问问题；当外部模块需要读取或写入数据甚至调用时，也没有任何问题功能。

您不需要减速器，您不需要生产者，您不需要消费者...您不需要其他任何东西。

使用ES6只是简单的ES6。

要设置组件状态：

Atomic.MyComponent().setState({x:"Atomic"});

调用组件函数：

Atomic.MyComponent().increasecount(); //(or any function)

要将状态变量加载到局部变量中： ” 让x = Atomic.MyComponent（）。state.x;

上述方法的优缺点是什么？

请仅以事实示例答复，而不是模糊的评论。

也很明显，某些Redux支持者对Redux十分狂热，以至于他们要么没有任何事实依据就发布虚假陈述（例如“内存泄漏”），要么只是在这里试图通过投票解决这个问题等候接听。

Answer 1

我认为这不是一个好的模式，因为它会鼓励使用意大利面条式代码-也就是说，您可以从任何地方访问任何组件并对其进行修改。实际上，将很难分析和调试代码路径。这正是Redux通过非常清晰地记录全局状态变化（也是一个很好的调试工具！）解决的问题。

我管理Redux的方式是，我仅将Redux用于真正的 Global 状态，即组件内部通信和全局配置所需的东西。本地状态应留在本地组件恕我直言。这样可以减少样板过载和不必要的复杂性。

@estus指出，处理多个组件实例时，您的解决方案会出现问题。

React —简化的数据存储而不是Redux，优缺点是什么？

1 个答案: