【问题标题】:Are there drawbacks in using classes to construct redux store?使用类来构建 redux store 有缺点吗?
【发布时间】:2020-02-14 15:29:09
【问题描述】:

我们的一位开发人员建议最好不要使用类来构建 redux 存储,但没有给出具体原因,主要是说“它不是惯用的,并且类在 ES6 中没有很好的实现;最好避免在 React 中使用类”。

以这种方式构建 redux 存储是否存在任何问题(即使它实际上不是行业标准?)?

class Item {
  public name: string;
}

class ItemState {
  public items: Item[];
  public currentItem: Item;
}

// redux store
class AppState {
  public Items = new ItemState();
}

// then createStore(/*reducer*/, new AppState())

【问题讨论】:

    标签: typescript ecmascript-6 react-redux


    【解决方案1】:

    想到的一件事是序列化。如果您想支持水合作用和时间旅行调试等功能,您需要能够序列化您的商店并恢复它。

    您的示例类不使用任何方法或继承,所以这对您来说可能不是问题。但是,如果您打算添加这些内容,请注意您可能会将自己与我提到的功能隔离开来。

    另见this section of the redux documentation

    【讨论】:

    • 是的,我意识到这些类需要是没有行为的纯 DTO。从技术上讲,我可以将它们声明为几乎没有变化的接口或类型。
    【解决方案2】:

    在我有限的经验中...我没有以这种方式使用类,但我使用了复杂的对象作为我的 redux 存储的一部分。我所说的复杂对象是指我的一些状态变量是具有不同属性的对象以及其中包含其他对象的数组。他们工作,所以我认为没有理由不上课。但我建议尽可能避免使用它,因为随着应用程序的增长,它可能会使访问状态变得更加混乱。请注意,当您连接需要访问 currentItem 名称的组件时,您必须编写:

    function mapStateToProps(state)
    {
       return {currentItemName: state.Items.currentItem.name};
    }
    

    这对我来说似乎太长了。 即使您将 state.Items 直接传递给您的组件,在某些时候您也需要访问 currentItem 的名称并且需要编写完全限定名称。我认为选择主要取决于应用程序的特定方面。但正如我所说,我的经验是有限的,我已经使用类来制作我的 redux 商店。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-04-30
      • 2019-12-27
      • 1970-01-01
      • 1970-01-01
      • 2018-03-01
      • 2021-12-26
      • 2021-09-21
      • 2011-01-09
      相关资源
      最近更新 更多