【问题标题】:Pass the entire global state to 'mapStateToProps'将整个全局状态传递给“mapStateToProps”
【发布时间】:2018-08-19 13:48:48
【问题描述】:

我想将整个全局状态传递给redux connect 'mapStateToProps'函数

在我的组件中,我可以访问现在是全局状态的状态。

这有什么问题吗?

我不想将状态分成许多块并将其切片到每个组件,而只是给出整个全局状态。

这有什么性能问题吗?我知道它会重新渲染整个组件,但是使用 react 的差异算法我想应该没问题。

使用“this.props.count”不像使用“this.props.todoSection.count”那样具有暗示性。只是一个可读性的东西。

我读到 react 1.6 中的“时间切片 api”可能会改善与维护全局状态相关的各种性能问题。

https://auth0.com/blog/time-slice-suspense-react16/

【问题讨论】:

  • 你能分享你的代码吗?
  • 不,我认为这是不言自明的。在 connect->mapstatetoprops 中,只需传递整个状态,而不是挑选您在组件中使用的状态的任何部分。

标签: reactjs redux react-redux


【解决方案1】:

技术上这是可能的,但更好的做法是在每个使用全局状态的组件中创建mapToStateProps。并在其中映射唯一需要的道具。

【讨论】:

  • (赞成;只是一个建议)也许更好地使用单词 map 而不是 pass 作为 pass 建议的 mapStateToProps 参数?
  • 这是正确答案。连接更多组件通常会更好地提高性能,因为每个组件只需要存储状态的一小部分,因此大多数情况下它不需要重新渲染。
【解决方案2】:

然后呢?每当状态中的任何地方发生变化时,无论它是否与您的组件相关,您的组件都会重新呈现?

为什么你会想要这样的东西? (只是好奇)

【讨论】:

  • 感谢您的回答。我认为为了可读性,拥有一个全局状态要比将多个局部状态映射到全局状态的一部分要好得多。使用“this.props.count”不像使用“this.props.todoSection.cout”那样具有启发性。只是一个可读性的东西。重新渲染整个链组件的性能问题真的很糟糕吗?
  • 这真的很糟糕,有几个原因,其中两个最重要的是:1)性能(你的应用程序会不断重新渲染,很快就会变成无用的 ui)和 2)你正在破坏组件封装:您希望组件有一个单一/狭窄的任务,并且您希望它只获取它需要的数据。我没有看到任何可读性提升,因为它只是命名:this.props.count > this.props.todosCount
  • 它没有将 'this.props.count' 重命名为 'this.props.todoscount',而是重命名为 this.props.todoSection.count。现在您无需查看连接的定义就知道“计数”的确切来源。
  • 我的意思是,如果像 this.props.count 这样的名称会给您带来可读性问题,请使用像 this.props.todosCount 这样的模式描述
  • 通过查看同一组件中的mapStateToProps,您无论如何都知道它来自哪里
【解决方案3】:

听起来您想要映射整个全局状态,只映射相关的 reducer。所以你当然可以只映射那个商店:

const mapStateToProps = ({ todoStore }) => ({ todoStore });

这比映射整个商店的成本要低得多,但如果商店变得足够大(和/或最终用户的浏览器足够糟糕),它可能会开始导致整个应用出现性能问题。充其量它是一种反模式。


使用this.props.count 不像使用this.props.todoStore.count 那样具有暗示性。只是为了可读性。

可以始终使用命名空间,同时仍然只映射您需要的数据:

const mapStateToProps = ({ todoStore: { count, foo } }) => ({ todoStore: { count, foo } });

这将为您提供所需的形状,同时仅连接所需的状态。但是伴随着重复属性名称的少量开发成本 - 并且仍然需要定义要映射的状态 - 这可能会破坏目的。

【讨论】:

  • 我承认:我 am 目前正在这样做 - 将整个 reducer 映射到状态(不知道更好) - 这导致了一些明显的延迟速度较慢的设备。
猜你喜欢
  • 2021-05-30
  • 1970-01-01
  • 2018-11-04
  • 2016-09-26
  • 1970-01-01
  • 2019-03-08
  • 2014-05-14
  • 1970-01-01
  • 2017-08-14
相关资源
最近更新 更多