Flux 架构嵌套和非单例存储

Posted 2023-02-22

【中文标题】Flux 架构嵌套和非单例存储

【英文标题】：Flux architectures nested and non-singleton stores

【发布时间】：2015-10-02 13:07:20

【问题描述】：

我在页面加载时获得了所有数据，JSON 如下所示：

  users: [
    
      userId: 1,
      messages: [
        
          messageId: 1,
          lines: [/* array of lines */]
        ,
        
          messageId: 2,
          lines: [/* array of lines */]
                  
      ],
    ,
    
      userId: 2,
      messages: [
        
          messageId: 3,
          lines: [/* array of lines */]
        ,
        
          messageId: 4,
          lines: [/* array of lines */]
                  
      ],
    ,
  ]

作为我的问题的一个例子，假设我正在尝试实现消息选择功能。每个用户一次只能有一条消息selected。当我调用动作创建者selectMessage(messageId) 并将其传递给我的MessagesStore 时，我如何知道应该选择哪个用户的消息？

我看到的唯一选择是将userId 传递到视图层次结构中，然后将其添加到动作创建器中——在UsersStore 中而不是在MessagesStore 中处理动作。我认为架构错了吗？

【问题讨论】：

您在这个问题中就问题的业务逻辑做出的假设。什么是角度……什么是夹子？？让您的问题更加概括，以便社区更容易使用，而不仅仅是您自己的问题领域。

@AndrewMcLagan 对不起，你能更清楚你在找什么吗？也许应该用不同的措辞，但您可以将angles 和clips 换成您想要的任何其他名词，这只是一个关于存储中的嵌套数据和维护单例模式的问题。让我知道如何才能更清楚地说明这一点。

@AndrewMcLagan 不确定这是否更清楚。但我试图让它比angles 和clips 更深奥，并重新表述了这个问题。让我知道这对您是否更有意义。

谢谢，这更清楚了。我以同样的方式处理了这个问题，只是传递了任意变量。我相信有更好的方法。我将进一步研究并回到这篇文章。

【参考方案1】：

选择将其保存到哪个商店取决于您选择如何将商店与组件相关联。有些人认为每个组件都应该有自己的商店。 （我不）。其他人试图将存储视为资源（如在 REST 中）。听起来这就是您要学习的内容？

这当然也行得通，但我一直认为资源的基本概念（如 RESTful 架构中所表达的那样）有些人为和限制。我更愿意将商店视为相关数据的集合，但没有资源的强大结构凝聚力。

这是一种相当冗长的说法，我认为您概述的任何一种方法都可以。我试图问自己的问题是：以后，当我的应用程序变得更大时，是否会很明显哪个存储区将保存特定位的数据？