在构建带有react＆amp; amp;的应用程序时，我发现很少有关于如何定义商店的信息。通量（特别是Fluxxor）。我的同事，其中大多数都有Backbone和其他MVC框架的经验，倾向于创建基本上是集合的商店（即BlogPostStore，CommentStore）。我的直觉是，商店非常故意不称为收藏品或模型。在flux docs,商店被解释为代表逻辑域的集合和单例，而没有真正解释何时应该使用一种形式或另一种形式。
是否有最佳做法或经验法则来决定何时应该定义基本上是收藏品或更具体的单身人士的商店？
答案 0 :(得分：1)
在我看来，在使用flux时划分商店的最佳方法是围绕域概念。需要管理博客帖子和评论？博客文章商店和评论商店（每个商店都充当其数据类型集合的容器）是有道理的。是否需要通过客户端操作管理的身份验证数据会话？会话商店 - 根本不管理集合，只是一堆与会话相关的数据 - 是完全合法的。您链接到的文档中提到的TimeStore是另一个很好的例子。
基本上，只要您处理新的＆＃34;类型＆＃34;不适合现有商店的信息，创建一个新商店。 （几年前有一次谈话，来自雅虎的人说他们有一个拥有超过100家商店的应用程序。）然后，在商店本身，为你想要的任何类型的数据管理实现动作处理程序;如果它是处理某事物集合的商店，那么您定义的动作类型和处理程序将反映出这一点。如果没有，那也很好。