难道 Redux 不是美化了全局状态吗?

因此,我一周前开始学习 React,不可避免地遇到了状态问题,以及组件应该如何与应用程序的其余部分进行通信。我四处寻找,终极版似乎是这个月的风味。我阅读了所有的文件,我认为这是一个非常革命性的想法。以下是我对此的看法:

状态通常被认为是非常邪恶的,是编程中大量 bug 的来源。与其把它们散布在你的应用程序中,Redux 说为什么不把它们集中在一个全局状态树中,你必须发出动作来改变它们呢?听起来很有趣。所有程序都需要状态,所以让我们把它固定在一个不纯净的空间,只从那里修改它,这样 bug 很容易追踪。然后,我们还可以声明性地将各个状态片段绑定到 React 组件,并让它们自动重绘,一切都是美丽的。

然而,我对整个设计有两个问题。首先,为什么状态树需要是不可变的?假设我不关心时间旅行调试、热重载,并且已经在我的应用程序中实现了撤销/重做。不得不这样做似乎太麻烦了:

case COMPLETE_TODO:
return [
...state.slice(0, action.index),
Object.assign({}, state[action.index], {
completed: true
}),
...state.slice(action.index + 1)
];

而不是这样:

case COMPLETE_TODO:
state[action.index].completed = true;

更不用说,我正在制作一个在线白板,只是为了学习和每个状态的变化可能是一样简单的添加到命令列表笔画。过了一段时间(数百个笔画) ,复制整个数组可能会变得非常昂贵和耗时。

我可以接受一个全局状态树,它独立于通过操作变异的 UI,但是它真的需要是不可变的吗?这样一个简单的实现(非常粗略的草案)有什么问题吗。在1分钟内写完) ?

var store = { items: [] };


export function getState() {
return store;
}


export function addTodo(text) {
store.items.push({ "text": text, "completed", false});
}


export function completeTodo(index) {
store.items[index].completed = true;
}

它仍然是一个全局状态树,通过发出的动作变异,但极其简单和高效。

12661 次浏览

Isn't Redux just glorified global state?

Of course it is. But the same holds for every database you have ever used. It is better to treat Redux as an in-memory database - which your components can reactively depend upon.

Immutability enables checking if any sub-tree has been altered very efficient because it simplifies down to an identity check.

Yes, your implementation is efficient, but the entire virtual dom will have to be re-rendered each time the tree is manipulated somehow.

If you are using React, it will eventually do a diff against the actual dom and perform minimal batch-optimized manipulations, but the full top-down re-rendering is still inefficient.

For an immutable tree, stateless components just have to check if the subtree(s) it depends on, differ in identities compared to previous value(s), and if so - the rendering can be avoided entirely.

Yes it is!!! Since there is no governance of who is allowed to write a specific property/variable/entry to the store and practically you can dispatch any action from anywhere, the code tends to be harder to maintain and even spaghetti when your code base grows and/or managed by more than one person.

I had the same questions and issues with Redux when I started use it so I have created a library that fix these issue:
It is called Yassi:
Yassi solves the problems you mentioned by define a globally readable and privately writable store. It means that anyone can read a property from the store (such as in Redux but simpler).
However only the owner of the property, meaning the object that declare the property can write/update that property in the store

In addition, Yassi has other perks in it such as zero boilerplate to declare entry in the store by using annotations (use @yassit('someName'))
Update the value of that entry does not require actions/reducers or other such cumbersome code snippets, instead just update the variable like in regular object.