所以我在一周前开始学习React,我不可避免地遇到了状态问题以及组件应该如何与应用程序的其余部分进行通信.我四处搜索,Redux似乎是这个月的味道.我阅读了所有文档,我认为这实际上是一个非常具有革命性的想法.以下是我的想法:
国家通常被认为是非常邪恶的,并且是编程中的大量漏洞.而不是在整个应用程序中散布它全部Redux说为什么不把它全部集中在一个全局状态树中,你必须发出改变的动作？听起来不错.所有程序都需要状态,所以让我们把它放在一个不纯净的空间中,只在那里修改它,这样就很容易找到错误.然后我们也可以声明性地将各个状态片段绑定到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;
}
它仍然是一个通过发出的动作而变异的全局状态树,但非常简单和有效.
我一直在使用Flux和Redux以后很长一段时间,我确实喜欢它们,我看到了它们的好处,但我脑海中浮现的一个问题是:
为什么我们要分解动作和减少器,并在表示改变状态(动作)的意图的调用和更改状态(减速器)的实际方式之间添加额外的间接,以这种方式更难以提供静态或运行时保证和错误检查？为什么不使用修改状态的方法或函数？
方法或函数将提供静态保证(使用Typescript或Flow)和运行时保证(未找到方法/函数等),而未处理的操作根本不会引发任何错误(静态或运行时),您只需要看到预期的行为没有发生.
让我用理论状态容器(TSC)更好地举例说明:
所以,你唯一需要的是触发组件重新绘制时,我们TSC的状态改变,并有可能改变这种状态,这对我们来说将是修改状态平原方法:fetchData,setError,setLoading等.
我看到的是动作和减速器是动态或静态调度代码的分离,因此不是叫myStateContainer.doSomethingAndUpdateState(...)你调用actions.doSomethingAndUpdateState(...),而是让整个flux/redux机器将该动作连接到状态的实际修改.这一切也带来了thunk,sagas和其他中间件处理更复杂动作的必要性,而不是仅使用常规的javascript控制流.
主要问题是这种解耦需要你编写很多东西才能实现这种解耦: - 动作创建者函数的接口(参数) - 动作类型 - 动作有效负载 - 你的状态的形状 - 你如何更新你的状态
将此与我们的理论状态容器(TSC)进行比较: - 您的方法的接口 - 您的州的形状 - 您如何更新您的州
那我在这里错过了什么？这种脱钩有什么好处？
这与其他问题非常相似:Redux动作/减速器与直接设置状态
让我解释为什么对这个问题的最多投票答案不能回答我或原来的问题: - 行动/减少者让你问问谁和如何？这可以通过我们的TSC完成,它只是一个实现细节,与动作/减速器本身无关. - 动作/减少器让你回到你的状态:再次这是状态容器的实现细节问题,可以通过我们的TSC实现. - 等等:状态变更单,中间件以及当前通过操作/减速器实现的任何事情都可以通过我们的TSC来实现,这只是它的实现问题.
非常感谢!弗兰