实施Flux后,很容易看出它实际上是单向的。
Flux概述:View接收用户操作,这些操作将被发送到Action Creators并由其解释,后者将被发送到Dispatcher,Dispatcher将广播到Stores,最终会在View中触发更新。
使用Redux,虽然我只阅读了一些关于它的博客文章,但似乎Action Creators实际上将格式化的动作对象返回到首先触发动作的View。
请参阅:https://code-cartoons.com/a-cartoon-intro-to-redux-3afb775501a6#.3hquuzljm
所以问题是:通过设计将Action Creator返回到View会破坏单向工作流的概念吗?
我还没有实现Redux,所以也许我错过了一步,但这对我来说是Flux和Redux之间的一个巨大差异。
答案 0 :(得分:1)
我认为你过分强调创作者的动作。
动作创作者就是这样:
function login(username, password) {
return { type: 'LOGIN', payload: { username, password };
}
这两件事情完全相同:
class Component extends React.Component {
...
render() {
const { username, password } = this.props;
return (
...
dispatch({ type: 'LOGIN', payload: { username, password });
// or
dispatch(login(username, password));
...
);
}
}
然后,如果您使用react-redux
的{{1}},它可能看起来像
connect
动作创作者不是一个大抽象。它们只是一个函数的特殊名称,可帮助您执行操作以保持代码干燥。他们没有做任何改变单向模型的事情。
答案 1 :(得分:0)
Flux和Redux中的数据流几乎相同,您只是没有Dispatcher和回调,因为操作在store上运行。 (将其与this flux diagram进行比较。)
Redux文档有a great chapter on this topic:
Redux架构围绕严格的单向数据 流量强>
这意味着应用程序中的所有数据都遵循相同的生命周期 模式,使您的应用程序的逻辑更容易预测和更容易 了解。它还鼓励数据规范化,因此您不会 最终得到相同数据的多个独立副本 不知道彼此。
如果您还不相信,请阅读 动机和The Case for Flux 一个有利于单向数据流的令人信服的论据。 虽然Redux is not exactly Flux,但它 分享同样的关键利益。
任何Redux应用程序中的数据生命周期都遵循以下4个步骤:
- 您致电
store.dispatch(action)
。- Redux商店调用您提供的reducer功能。
- 根减速器可以将多个减速器的输出组合成单个状态树。
- Redux存储保存根减速器返回的完整状态树。
醇>
答案 2 :(得分:0)
让Action Creator按设计返回View会破坏单向工作流的概念吗?
redux中的动作创建者返回动作而不调用dispatch。正确。 这是否打破了单向工作流程?否。
从动作创建者接收到动作后,可以通过调用dispatch()函数将其返回到商店,并将返回的动作作为参数。因此,数据流仍然是单向的。
在传统的Flux实现中,动作创建者经常在调用时触发调度,如下所示:
function addTodoWithDispatch(text) {
const action = {
type: ADD_TODO,
text
}
dispatch(action)
}
相比之下,在Redux中,动作创建者是纯函数,没有副作用。他们只是回复一个动作:
function addTodo(text) {
return {
type: ADD_TODO,
text
}
}
这使它们更便于携带,更易于测试。要实际启动分派,请将结果传递给dispatch()函数:
dispatch(addTodo(text))
dispatch(completeTodo(index))
http://rackt.org/redux/docs/basics/Actions.html
如https://code-cartoons.com/a-cartoon-intro-to-redux-3afb775501a6#.e9br039va
所示视图请求操作。动作创建者对其进行格式化并将其返回。
自动调度操作(如果在安装中使用了bindActionCreators()),或者视图调度操作。
商店收到行动。
因此数据流仍然是单向的。