开门见山：Flux架构中的单元转换（用于显示和输入）、权限检查和其他与表示相关的转换等行为属于哪里？
在我们的案例中，"其他与演示文稿相关的转换"的一个示例是将用户布局设置应用于视图。例如，用户可以定义要在摘要视图中查看的数据字段，以及查看这些字段的顺序。
我们认为我们理解了这个问题解决方案的一部分：这些转换是应用程序状态，并存在于各种状态存储中（"WeekSummaryLayoutStore"、"UnitPreferencesStore"）。设置/获取、编辑和检索这些状态的流程是众所周知的。
我们想探索的是在哪里应用这些状态，以获得最终的演示结果，并与Flux架构保持一致。我们提出了多种选择：
1） React组件Mixin在每个叶组件的"render"方法中处理单元转换之类的事情。各种表示状态存储被DI’ed到组件的构造函数中，Mixin自动连接（监听各种状态存储、更新等）。
2） 使用一个中间存储WeekSummaryPresentationDataStore，它监听WeekSummariDataStore、WeekSummary LayoutStore和UnitPreferencesStore，并吐出最终的演示数据；该组件然后收听适当的***PresentationStore并处理更新&与其他商店一样进行渲染。
3） 将所有转换集成到原始数据存储中，并让存储只吐出可用于表示的数据。
支持/反对每一项的论点？
1） 最后一个叶子组件应该是唯一知道如何"呈现"数据的模块。可以说，单元转换、应用布局和基于权限确定数据细节都是这种表示逻辑的一部分。几个额外的层，但很好地解耦了，原始数据存储不需要知道任何关于进一步转换的信息。每个存储的核心业务逻辑可以跨组件重用，然后每个组件可以基于各种表示状态存储以不同的方式呈现数据。
2） 增加了什么的复杂性？
3） 可以说，某些表示逻辑是业务逻辑的一部分，并且可能由核心数据存储所拥有。显著降低了复杂性，但如果组件需要相同的核心存储但不同的表示状态，则允许重复业务逻辑。
想法？
如果转换是"纯"函数，那么它们可以存在于Utils模块中。例如，DateTimeUtils。我指的是函数编程意义上的"纯"：无状态，不需要任何不通过方法参数传递的有状态信息。相同的输入总是产生相同的输出。
Util是静态函数包，没有特定于应用程序的依赖关系（尽管WebAPIUtil模块是此规则的一个显著例外，因为它需要API调用所需的存储中的所有数据）。现在，任何需要这些应用程序依赖项的组件或存储都可以需要这些无应用程序依赖性的Utils模块。
当然，您可以为视图层创建一个mixin。但我个人更喜欢静态方法Utils模块而不是mixin，因为它更容易理解方法的定义位置。
至于是否应该存储转换，我认为您可能不应该，但这可能需要根据具体情况来决定。这感觉就像是将视图层和数据层紧密耦合，它们可能应该更独立地运行。