Question

我在React开发方面还很陌生，但是我已经使用React + Redux处理了3个大项目，我看到了一个我不喜欢的模式：

componentWillReceiveProps(nextProps) {
    if (nextProps.params.type === TYPE_NEW_USER) {
      this.modalUsername = this.props.showPopup( < NewUsernamePopup onClose = {::this.closeUsernamePopup
        }
        />, USERNAME_POPUP_ID, true); 
      }
      if (this.state.kind !== nextProps.kind || this.state.filter !== nextProps.filter || this.state.hashtags !== nextProps.hashtags) {
        this.setState({
          results: [],
          loading: true,
          kind: nextProps.kind,
          filter: nextProps.filter,
          hashtags: nextProps.hashtags
        }, () => this.manageResults(nextProps.results, false));
      } else {
        this.manageResults(nextProps.results, true);
      }
      this.managePages(nextProps.paging);
}

我想避免在componentWillReceiveProps中使用ifs。你怎么处理它？我们使用Flux和回调注册分析了另一个项目。它看起来像：

componentWillMount() { 
  EntityStore.on(EntityActions.ENTITIES_LOADED, this.getData.bind(this)); 
  EntityActions.entitiesLoaded(); 
}

第一个事件由组件发出，但之后商店发出事件并更新组件。此外，单个存储保持其状态，如果已存在内容，则不会复制异步调用。我个人喜欢避免使用ifs，但我不想丢失Redux（它的社区和工具）。

如何在组件外部的componentWillReceiveProps中添加当前逻辑（ifs）？我想处理服务层中的逻辑而不是组件内部。

我非常感谢您阅读您对此的看法，因为我一直在努力寻找适合的解决方案。

Answer 1

redux方法是将逻辑放入actions / reducers中。

所以我不知道你的manageResults方法做了什么，但它可能是你想要进入reducer的逻辑部分，所以你不需要再从你的组件中调用它。

因此，kind，filter和hashtags变量应仅从redux操作更新。

Answer 2

正确遵循redux最佳实践的dr会消除其中的一些条件，但我会更关注这个片段所揭示的整体设计。

解决各个问题：

if (nextProps.params.type === TYPE_NEW_USER) {

这看起来像是将redux操作传递给组件？如果是这样，那不是很好，只有减速器应该关注动作类型。

this.modalUsername = this.props.showPopup(

生命周期钩子componentWillReceiveProps不适合发起这样的事情，实例var中生成的React组件看起来也很奇怪。

if (this.state.kind !== nextProps.kind || this.state.filter (etc.) ) {

如果你在这个组件中的UI状态某种程度上依赖于来自redux的道具，那么这些类型的ifs在某种程度上是必要的，因为你不能在组件之外进行。

你不喜欢这种“模式”，这似乎反映了糟糕的整体设计。这个组件似乎涉及“页面”，“结果”，用户名和一些带有加载标志的ajax。当然只能推测，但似乎它做得太多了。 ajax请求生命周期绝对应该在reducer中建模。

也就是说，生命周期钩子经常包含一堆ifs，因为reducers没有看到路由以及哪些组件被挂载/卸载，所以这就是你必须对改变道具做出反应的地方。

componentWillReceiveProps包含许多ifs

2 个答案: