我想知道拥有"胖"gDSFP函数是否是一种不好的做法。目前，我有一个组件可以接收一些数据并进行一堆数据操作
function getDrivedStateFromProps(nextProps, prevState) {
// start doing data manipulation
在此过程中，如果遇到错误条件，它会返回一个新的状态错误片
const someValue = nextProps.something * myFunc()
if (someValue === badThing()) {
return {error: true};
}
// continue doing data manipulation
在完成所有数据操作并返回我的组件所需的派生状态之前，这会重复几次。我很好奇社区对"胖"gDSFP 函数的看法。我的组件仅在外部数据源更改时运行 gDSFP，并且它需要派生新状态，因此我看不到此逻辑还可以存在于何处。
我认为您实际上可能处于使用getDerivedStateFromProps可能根本不是最佳方法的情况。在你的问题中，你说...
我的组件仅在外部数据源更改时运行 gDSFP，并且它需要派生新状态，因此我看不到此逻辑还可以存在于何处。
鉴于此声明，听起来您可以使用记忆。这是在反应文档中讨论的这个概念。
基本思想是，管理getDerivedStateFromProps可能会变得毛茸茸的，尤其是当你有很多逻辑时。如果您想在状态下捕获道具的原因只是为了获得性能提升，那么记忆可能是您的朋友。
这里的想法是，你不希望每次你的 props 更改时都运行一些逻辑，所以这将为你买到的是，如果你有一个函数的参数与以前相同，作为示例状态没有改变，你的函数将返回它存储在缓存中的最后一个计算结果。这个库很好地处理了这一点，并且非常易于使用。
人们经常遇到的另一个可能促使他们寻求getDerivedStateFromProps的担忧是确保他们的组件不会渲染，除非 props 实际上已经更改，因此通过让组件基于计算状态渲染可以实现这一点。
但这也可以在不使用getDerivedStateFromProps的情况下实现。使用PureComponent可以给你同样的结果，而且大惊小怪得多。另一个选项可以是 shouldComponentUpdate。
简而言之，除非您有一些非常具体的原因表明getDerivedStateFromProps适合您的用例，否则您最好寻求一种涉及较少拔毛的解决方案。