为什么在flux应用程序架构中每个实体使用一个商店？ [英] Why use one store per entity in the flux application architecture?

问题描述

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

I am using reactjs and the flux architecture in a project I'm working on. I am a bit puzzled by how to break up nested data correctly into stores and why I should split up my data into multiple stores.

要解释我将使用的问题这个例子：

To explain the problem I'll use this example:

想象一下你有项目的Todo应用程序。每个项目都有任务，每个任务都可以有笔记。

Imagine a Todo application where you have Projects. Each project has tasks and each task can have notes.

应用程序使用REST api检索数据，返回以下响应：

The application uses a REST api to retrieve the data, returning the following response:

{
    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"
                        }
                    ]
                }
            ]
        },
    ]
}

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

The fictive application's interface displays a list of projects on the left and when you select a project, that project becomes active and its tasks are displayed on the right. When you click a task you can see its notes in a popup.

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

What I would do is use 1 single store, the "Project Store". An action does the request to the server, fetches the data and instructs the store to fill itself with the new data. The store internally saves this tree of entities (Projects -> Tasks -> Notes).

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

To be able to show and hide tasks based on which project is selected I'd also keep a variable in the store, "activeProjectId". Based on that the view can get the active project, its tasks and render them.

问题解决了。

但是：在线搜索后看看这是否是一个很好的解决方案我看到很多人说你应该为每个实体使用一个单独的商店。

However: after searching a bit online to see if this is a good solution I see a lot of people stating that you should use a separate store per entity.

这意味着：
ProjectStore，TaskStore和NoteStore。为了能够管理关联，我可能还需要一个TasksByProjectStore和一个NotesByTaskStore。

This would mean: A ProjectStore, TaskStore and NoteStore. To be able to manage associations I would possibly also need a "TasksByProjectStore" and a "NotesByTaskStore".

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

Can someone please explain why this would be better? The only thing I see is a lot of overhead in managing the stores and the data flow.

推荐答案

有利弊使用一个商店或不同的商店。一些通量的实施特别支持一家商店统治它们所有，可以说，而其他商店也促进多个商店。

There are pro's and cons to use one store or different stores. Some implementations of flux specifically favour one store to rule them all, so to speak, while others also facilitate multiple stores.

无论一个商店或多个商店是否适合您的需求，取决于a）您的应用程序的功能，以及b）您期望的未来发展或变化。简而言之：

Whether one store or multiple stores suit your needs, depend on a) what your app does, and b) which future developments or changes you expect. In a nutshell:

• 如果关键问题是嵌套实体之间的依赖关系，那么一个商店会更好。如果您不太担心服务器存储组件之间的单个实体关系之间的依赖关系。一家商店很棒，例如您希望在项目级别管理有关基础任务和注释的统计信息。许多类似父子关系和一体化数据获取表单服务器都支持一种商店解决方案。


• 如果你的关键问题是依赖关系，那么多个商店会更好server-store-component之间的单个实体连接。弱的实体到实体关系和独立的单一实体服务器提取和更新有利于多个商店。

• One store is better if your key concern is the dependencies between your nested entities. And if you are less worried about dependencies between single entity relation between server-store-component. One store is great if e.g. you want to manage stats on project level about underlying tasks and notes. Many parent-child-like relationships and all-in-one data fetching form server favour one store solution.
• Multiple stores better if your key concern is dependencies between single entity connections between server-store-component. Weak entity-to-entity relationships and independent single entity server fetches and updates favour multiple stores.

在您的情况下：我的赌注是一家商店更好。您有明显的父子关系，并立即从服务器获取所有项目数据。

In your case: my bet would be that one store is better. You have evident parent-child relationship, and get all project data at once from server.

答案稍长：

一个商店：

• 非常好地减少管理多个商店的开销。


• 如果您的顶级视图组件是唯一的有状态组件，并且从商店获取所有数据，并将详细信息分发给无状态子级，则此方法很有效。


• 但是，管理实体之间依赖关系的需要并不会消失：您需要在单个商店内管理它们，而不是在不同商店之间管理它们。因此，它变得更大（更多的代码行）。


• 此外，在典型的磁通设置中，每个商店都会发出一个我已经改变的事件，并将其留给组件来确定改变的内容以及是否需要顶部重新渲染。因此，如果您有许多嵌套实体，并且其中一个实体从服务器接收到许多更新，那么您的超市将发出许多更改，这可能会触发整个结构和所有组件的大量不必要的更新。 Flux-react可以处理很多，并且细节更改 - 更新 - 一切都处理得很好，但它可能不适合每个人的需求（我不得不放弃这种方法，当它搞砸了我在一个项目中的状态之间的转换）。

• Great to minimize overhead of managing multiple stores.
• It works well if your top view component is the only stateful component, and gets all data from the store, and distributes details to stateless children.
• However, the need to manage dependencies between your entities does not simply go away: instead of managing them between different stores, you need to manage them inside the single store. Which therefore gets bigger (more lines of code).
• Also, in a typical flux setup, each store emits a single 'I have changed' event, and leaves it up to the component(s) to figure out what changed and if they need top re-render. So if you have many nested entities, and one of the entities receives many updates from the server, then your superstore emits many changes, which might trigger a lot of unnecessary updates of the entire structure and all components. Flux-react can handle a lot, and the detail-changed-update-everything is what it handles well, but it may not suit everyones needs (I had to abandon this approach when it screwed up my transitions between states in one project).

多个商店：

• 更多开销，是的，但对于某些项目，您也可以得到回报


• 如果您在服务器数据和组件之间有紧密耦合，并且其间有磁通存储，那么更容易在不同的商店中分离顾虑


• 如果例如您期望对注释数据结构进行许多更改和更新，而不是更容易拥有注释的有状态组件，它会侦听注释存储，注释存储又会从服务器处理注释数据更新。处理笔记结构中的更改时，您可以只关注笔记本，而无需弄清楚如何在一些大型超市内处理笔记。

这篇关于为什么在flux应用程序架构中每个实体使用一个商店？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！