2

直截了当：单位转换（用于显示和输入）、权限检查和其他与表示相关的转换等行为属于 Flux 架构的什么地方？

在我们的案例中，“其他与演示相关的转换”的一个示例是将用户布局设置应用于视图。例如，用户可以定义在摘要视图中查看哪些数据字段，以及查看这些字段的顺序。

我们认为我们理解了这个问题解决方案的一部分：这些转换是应用程序状态并且存在于各种状态存储中（“WeekSummaryLayoutStore”、“UnitPreferencesStore”）。设置/获取、编辑和检索这些状态的流程很好理解。

我们想探索的是在哪里应用这些状态以获得最终的呈现结果并与 Flux 架构保持一致。我们提出了多种选择：

1) React 组件 Mixin 在每个叶子组件的“render”方法中处理单元转换之类的事情。各种表示状态存储被 DI'ed 到组件的构造函数中，并且 Mixin 自动将事物连接起来（监听各种状态存储、更新等）。

2）使用中间存储WeekSummaryPresentationDataStore，它监听WeekSummaryDataStore、WeekSummaryLayoutStore和UnitPreferencesStores，并吐出最终的展示数据；然后该组件监听正确的 ***PresentationStore 并像处理任何其他商店一样处理更新和渲染。

3) 整合原始数据存储中的所有转换，并让存储仅吐出可呈现的数据。

支持/反对每个的论点？

1）最终的叶子组件应该是唯一知道如何“呈现”数据的模块。可以说，单位转换、应用布局和基于权限确定数据细节是此表示逻辑的一部分。几个额外的层，但很好地解耦，原始数据存储不需要了解任何关于进一步转换的信息。每个存储的核心业务逻辑可以跨组件重用，然后每个组件可以根据不同的呈现状态存储以不同的方式呈现数据。

2) 增加了什么复杂性？

3) 可以说，一些表示逻辑是业务逻辑的一部分，可以归核心数据存储所有。显着降低复杂性，但如果组件需要相同的核心存储但不同的表示状态，则允许重复业务逻辑。

想法？

4

1 回答 1

2

如果您的转换是“纯”函数，那么它们可以存在于 Utils 模块中。例如，日期时间实用程序。我的意思是函数式编程意义上的“纯”：无状态，不需要任何未通过方法参数传入的有状态信息。相同的输入总是产生相同的输出。

Utils 是静态函数包，没有特定于应用程序的依赖项（尽管 WebAPIUtils 模块是此规则的一个明显例外，因为它需要 API 调用所需的存储中的所有数据）。这些不依赖应用程序的 Utils 模块现在可以在任何需要它们的组件或商店中使用。

当然，您可以为视图层创建一个 mixin。但我个人更喜欢静态方法 Utils 模块而不是 mixins，因为它更容易理解方法的定义位置。

至于您是否应该存储转换，我认为您可能不应该，但这可能需要根据具体情况来决定。这感觉就像紧密耦合您的视图和数据层，它们可能应该更独立地运行。

于 2014-10-27T19:41:03.930 回答