Javascript 在redux action创建者内部设置侦听器是个坏主意吗?

Javascript 在redux action创建者内部设置侦听器是个坏主意吗?,javascript,reactjs,react-native,redux,redux-thunk,Javascript,Reactjs,React Native,Redux,Redux Thunk,我正在构建一个应用程序,它不断地监听位置变化并更新商店。我想知道将我的侦听器放在动作创建者中而不是组件本身是否是一个好主意 比如说, componentWillMount(){ this.props.watchLocation(); } //内部行动创造者 导出函数watchLocation(){ LocationManager.on(“位置”,位置=>{ 调度位置); }); }如果在action creator或组件本身中设置侦听器,性能应该不会有任何差异,但我认为在action crea

我正在构建一个应用程序,它不断地监听位置变化并更新商店。我想知道将我的侦听器放在动作创建者中而不是组件本身是否是一个好主意

比如说,

componentWillMount(){
this.props.watchLocation();
}
//内部行动创造者
导出函数watchLocation(){
LocationManager.on(“位置”,位置=>{
调度位置);
});

}
如果在action creator或组件本身中设置侦听器,性能应该不会有任何差异,但我认为在action creator中设置侦听器是一个好主意,因为您可以轻松访问action creator中的当前状态(使用redux thunk或其他包)并且允许代码更具可扩展性。

就性能而言,我认为这没有多大区别,但我不同意Varun关于听众位置的回答。如果创建这样一个操作并将其分派一次,则需要一个额外的操作来更新存储(当然,您可以使用thunk进行更新),并且以后可能很难禁用回调,因为您无法访问回调引用,因为它仅在操作调用中使用。如果使用componentDidMount/componentWillUnmount生命周期方法跟踪事件处理程序,则很容易避免内存泄漏。顺便说一下,不要将componentWillMount用于任何可能导致副作用的东西:

componentWillMount()在装入之前立即调用。它在render()之前调用,因此在此方法中同步设置状态不会触发重新渲染。避免在这种方法中引入任何副作用或订阅


有关更多信息,请参阅。

为什么需要额外的操作?如果你不放一点呢?对于定期作业,如果以后需要禁用它,可以触发一个操作将计时器id存储在存储中(如果使用setInterval),然后使用另一个操作禁用它。或者在这个API的情况下,您可能不需要存储任何东西,我猜有一个方法LocationManager.stopWatching。我喜欢Varun关于让代码更具可扩展性、模块化,并从组件中删除所有逻辑(只显示内容)的评论,因为您需要一个动作来开始侦听,另一个动作真正进入还原器。你是正确的,你可以在商店中存储定时器ID,但是因为它们很可能被绑定到组件的生命周期,所以我认为它有点过火(创建启用/禁用的动作,为它设置减速机),并注意在正确的位置调度动作。最后最有可能是componentDidMount/componentWillUnmount方法。此外,许多库都不会为您处理回调,例如,可以接受n个回调的事件侦听器(例如,一个简单的addEventListener)。如何告诉removeEventListener要停止使用哪个回调?您唯一的选择是对回调函数的引用。此外,在模块化方面,它几乎保持不变,在存储中有一个更新值的操作,在一个组件中有两个额外的行来跟踪发送更新的回调。好的,同意过度杀戮,是的,它很可能绑定到组件的生命周期。并同意eventListener(尽管我在过去3个月里一直没有使用过,所以没有面对它)。但是,在这种特定情况下,为什么您需要不惜一切代价在减速器中进行配对操作?没有什么强迫你(我有非常相似的动作,不会立即发送任何动作),它仍然是连贯的,因为它会在某个点发送动作。是的,Martin,你是对的,需要额外的动作来发送数据,我同意。事实上,我的应用程序由其他几种方法组成,这些方法只需要这些额外的方法,所以如果没有性能缺陷的话,我想我会接受这种设置。