最佳答案
因此,我一周前开始学习 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;
}
它仍然是一个全局状态树,通过发出的动作变异,但极其简单和高效。