时间戳

首页 > 解决方案 > Redux - 在 React 组件的构造函数中使用 bindActionCreators 有什么缺点吗？

javascript - Redux - 在 React 组件的构造函数中使用 bindActionCreators 有什么缺点吗？

问题描述

我已经看到很多在bindActionCreators函数中使用该函数的示例，mapDispatchToProps如下所示：

...
const mapDispatchToProps = (dispatch, props) => ({
    actions: bindActionCreators({
        doSomething: somethingActions.doSomething,
    }, dispatch)
});

export default connect(null, mapDispatchToProps)(SomeComponent);

这意味着每次存储更改时，此组件都会更新并重新执行将somethingActions.doSomething动作创建者包装在dispatch函数中并将其作为匿名函数返回。

像这样在构造函数中简单地执行一次不是更高效吗？

constructor(props) {
    super(props);

    const { dispatch } = props;

    this.boundActionCreators = bindActionCreators({
        doSomething: somethingActions.doSomething,
    }, dispatch);
}

这样做有什么缺点吗？

标签： javascriptreactjsredux

解决方案

mapDispatchToProps默认情况下，每个组件生命周期只使用一次 -请参阅 Redux GitHub 中的这个问题。它可以运行多次，理论上会导致性能问题。

可能引起麻烦的事情：

  • 关注点的拆分 -mapDispatchToProps作为单独的函数传递给connect()HOC 有助于未来的重构 - 很容易将连接移动到其他任何地方，扩展或完全删除它 - 无需单独更改组件。请参阅 Dan Abramov 的这篇关于 Presentational and Container Components的文章。在这种情况下，您的组件是 Presentational 并且connect()+ 它mapDispatchToProps是 Container。
  • 代码可重复性 - 构造函数可能会变得非常冗长和混乱 - 想象一下必须使用boundActionCreators10 次。
  • 使用actions- 在您的解决方案中，您需要将操作this.nameOfAction()发送到 redux。但是对于获取数据，你会做this.props.nameOfDataProp. 以相同的方式访问所有Redux功能（又名 via props）有助于可重复性和维护。
  • 此外，性能提升将是可分割的 - 因为mapDispatchToProps仅在依赖于props. 我鼓励您在您的应用程序中对此进行测试，看看您是否可以获得足够好的性能提升。

TL;DR：你可以获得一些小的性能提升，但在代码维护和可重复性方面需要付出很大的代价。

推荐阅读