Question

我想知道是否有任何理由避免这种模式：

我认为React Native已经这样做，例如<ListView renderRow />

Answer 1

就个人而言，我会避免这样的app-flow，其中Component正在做那么多，比如获取和操作数据。

React的主要思想是(data) => (view) 一个函数（首选纯函数），它返回视图..

诸如获取数据，更改商店，处理身份验证之类的事情应该转移到单独的模块并运行某些操作。

这样你就可以独立于视图层了，所以你可以把你的api-stuff放到angular，backbone，jquery中，甚至可以在服务器上运行它。

我认为这样做没有任何好处，也许你可以为你的方法写一些独特的卖点，会很好。

Answer 2

模式非常好。不是每个I / O场景都可能，但是对于您知道必须先加载之前进行渲染的资源的URL的情况。我甚至会改进它。

This parameter实际上看起来像无状态函数React组件。因此，将其定义移出渲染，并将其定义为（无状态）组件（作为函数）。

然后，应修改this line以使用每个组件，而不仅仅是函数。此外，我会延迟渲染到你的AJAX完成的那一刻。像这样：

  return this.props.renderComponent({ ...this.state, fetch: this.fetch })

- ＆GT;

  return this.state.fetching ? <div/> : <this.props.renderComponent {...this.state } fetch={ this.fetch } />;

删除try-catch。不需要 - 现在只有在数据就绪时才会安装组件，因此他们可以假设他们的数据同步，数据流是声明性的。这就是我们想要的，不是吗？

这种模式的巨大好处是什么，我认为没有任何合理的理由需要避免。