为什么在flux应用程序架构中每个实体使用一个商店？

Question

我在我正在研究的项目中使用reactjs和flux体系结构.我对如何将嵌套数据正确地分解到商店以及为什么我应该将数据分成多个商店感到困惑.

为了解释这个问题,我将使用这个例子:

想象一下你有项目的Todo应用程序.每个项目都有任务,每个任务都有笔记.

该应用程序使用REST API检索数据,返回以下响应:

{
    projects: [
        { 
            id: 1, 
            name: "Action Required",
            tasks: [
                {
                    id: 1,
                    name: "Go grocery shopping",
                    notes: [
                        {
                            id: 1,
                            name: "Check shop 1"
                        },
                        {
                            id: 2,
                            name: "Also check shop 2"
                        }
                    ]
                }
            ]
        },
    ]
}

虚拟应用程序的界面在左侧显示项目列表,当您选择项目时,该项目将变为活动状态,其任务将显示在右侧.单击任务时,您可以在弹出窗口中查看其注释.

我要做的是使用1个单独的商店,即"Project Store".操作会向服务器发出请求,获取数据并指示商店使用新数据填充自己.商店在内部保存这个实体树(项目 - >任务 - >注释).

为了能够根据选择的项目显示和隐藏任务,我还在商店中保留一个变量"activeProjectId".基于此视图可以获取活动项目,其任务并呈现它们.

问题解决了.

但是:在网上搜索一下以确定这是一个很好的解决方案后,我看到很多人都说你应该为每个实体使用一个单独的商店.

这意味着:ProjectStore,TaskStore和NoteStore.为了能够管理关联,我可能还需要一个"TasksByProjectStore"和一个"NotesByTaskStore".

有人可以解释为什么这会更好吗？我唯一看到的是管理商店和数据流的大量开销.

Answer 1

使用一家商店或不同商店有利弊.一些通量的实现特别有利于一家商店统治它们所有,可以说,而其他商店也促进多个商店.

无论是一家商店还是多家商店都能满足您的需求,取决于a)您的应用程序的功能,以及b)您期望的未来发展或变化.简而言之:

• 如果关键问题是嵌套实体之间的依赖关系,那么一个商店会更好.如果您不太担心服务器存储组件之间的单个实体关系之间的依赖关系.如果您想要在项目级别管理有关基础任务和注释的统计数据,那么一家商店就很棒.许多类似父子关系和一体化数据提取表单服务器都支持一种商店解决方案.
• 如果关键问题是服务器存储组件之间的单个实体连接之间的依赖关系,那么多个存储会更好.弱的实体到实体关系和独立的单实体服务器提取和更新有利于多个商店.

在你的情况下:我的赌注是一家商店更好.您有明显的父子关系,并从服务器一次获取所有项目数据.

更长的答案:

一家商店:

• 很好地减少管理多个商店的开销.
• 如果您的顶视图组件是唯一的有状态组件,并且从商店获取所有数据,并将详细信息分发给无状态子项,则它可以正常工作.
• 但是,管理实体之间依赖关系的需求不会消失:您需要在单个商店内管理它们,而不是在不同商店之间管理它们.因此,它变得更大(更多的代码行).
• 此外,在典型的磁通设置中,每个商店都会发出一个"我已经改变"的事件,并将其留给组件来确定改变了什么,以及它们是否需要顶部重新渲染.因此,如果您有许多嵌套实体,并且其中一个实体从服务器接收到许多更新,那么您的超市将发出许多更改,这可能会触发整个结构和所有组件的大量不必要的更新.Flux-react可以处理很多,并且细节更改 - 更新 - 一切都处理得很好,但它可能不适合每个人的需求(我不得不放弃这种方法,当它搞砸了我在一个项目中的状态之间的转换).

多家商店:

• 更多的开销,是的,但对于某些项目,您也可获得回报
• 如果服务器数据和组件之间存在紧密耦合,并且介于两者之间,则更容易在不同的存储中分离关注点
• 例如,如果您期望对注释数据结构进行许多更改和更新,那么就更容易拥有注释的有状态组件,它会侦听注释存储,注释存储又会从服务器处理注释数据更新.处理笔记结构中的更改时,您可以只关注笔记存储,而无需弄清楚如何在一些大型超市内处理笔记.