构建调用以更新全局和本地状态(Structuring calls to update global and local state)

构建调用以更新全局和本地状态(Structuring calls to update global and local state)

我的一些组件不希望全局存储所有状态。 两个例子：

messages组件：usermessages被提取并存储在本地，因为它们仅对当前组件是必需的。 但是当它们无法获取（api错误）时，应将错误调度到全局状态（vuex）。 buy组件：“最近购买”被提取并存储在本地，但“金钱”应该被分派到全局状态，并且当最近的购买无法获取时也会出错。

我正在弄清楚如何构建这个，我需要一些帮助。 我有一个目录services ，其中包括对我的api的调用。 我们以购买服务为例：

/services/buy.js：

// here code to dispatch money state // here code to dispatch 'last activity' state Vue.$http.get('/buy', credentials) .then((response) => { // return recent buys }) .catch((error) => { // here code to dispatch error state });

服务之间也存在一些逻辑：例如，成功购买后，应从/services/newMessage.js发送新消息

但是我应该如何以及在何处构建所有这些？ 我们以buy组件为例。 我看到了几个选项：

＃1： 这是上面的代码

buy-component导入购买服务并调用它： newBuy() 该服务将钱发送到全球商店，该服务获取最近的购买并返回它们 回到组件中，它使用服务返回的值更新本地存储 该组件也有逻辑：成功返回后，它调用消息服务发送新消息： sendMessage()

＃2： 与＃1的区别在于逻辑发生在服务中

组件导入购买服务并调用它： newBuy() 该服务将钱发送到全局存储，并导入消息服务 消息服务发送一条新消息： sendMessage() 回到购买服务，最近的购买被取回并返回。 该组件现在使用返回的值更新本地存储

＃3： 与上述步骤的不同之处在于，与Vuex相关的所有操作都在特殊的actions.js文件中，因此它明确区分了全局和本地状态更新。

组件导入购买服务并调用它： newBuy() 该服务导入./store/actions.js并调用更新钱的updateMoney()服务 继续进行＃1或＃2的步骤

有人可以帮帮我吗？ 如何组合使用全局和本地状态的组件？ 这是正确方法之上的三个步骤之一吗？

Some of my components doesn't want to store all state globally. Two examples:

messages component: usermessages are fetched and stored locally because they are only needed for the current component. But when they could not be fetched (api error), the error should be dispatched to global state (vuex). buy component: 'recent buys' are fetched and stored locally, but 'money' should be dispatched to global state, and error too when recent buys could not be fetched.

I'm currently figuring out how to structure this and I need some help. I have a directory services which includes calls to my api. Let's take the buy service as an example:

/services/buy.js:

// here code to dispatch money state // here code to dispatch 'last activity' state Vue.$http.get('/buy', credentials) .then((response) => { // return recent buys }) .catch((error) => { // here code to dispatch error state });

There are some logics between the services as well: For example, after a succesful buy, a new message should be sent from /services/newMessage.js

But how and where should I structure all of this? Let's take the buy component as an example. I see a couple of options:

#1: This is the code above

The buy-component imports the buy service and calls it: newBuy() The service dispatches the money to global store, and the service gets the recent buys and returns them Back in the component, it updates the local store with the returned value from the service The component has the logic too: after a succesful return, it calls the message service to send a new message: sendMessage()

#2: The difference with #1 is that the logic takes place inside the service

The component imports the buy service and calls it: newBuy() The service dispatches the money to global store, and imports the message service The message service sends a new message: sendMessage() Back to the buy service, the recent buys are fetched and returned. The component now updates the local store with the returned value

#3: The difference with steps above is that all actions related to Vuex are inside a special actions.js file, so it is a clear separation of global and local state updates.

The component imports the buy service and calls it: newBuy() The service imports ./store/actions.js and calls the updateMoney() service which updates the money Goes further with the steps from #1 or #2

Could someone please help me out? How to combine components that use both global and local state? Are one of the three steps above the right way to do that?

最满意答案

简而言之，根据您的情况： 选项2

对我来说，如果不需要在全球范围内共享一个州，那么你所做的就是通过写入所有内容来污染vuex的状态。

例如，如果您有10个组件的功能类似于购买组件，并且每个组件只从他们的vuex商店中提取个别状态，那么您将使vuex商店更难以推理。

此外，如果您开始为这些状态附加动作和突变，那么您可能需要为10个组件中的每个组件构建模块，再次模糊您的状态和逻辑。

因此，在这种情况下， 如果您确定不需要在其他地方检索的状态，则选项2似乎是更好的方法。 你似乎非常清楚为什么要使用vuex这样才能让你处于有利地位。 我想说，大型应用程序的一半工作是在规划中。 因此，如果您可以在构建连接所需的位置之前确定应用程序的运行和查看方式，并且反过来将组件数据完全隔离，您应该能够快速做出关于您做什么的决定并且不要做推到vuex。

就选项1和选项2之间的选择而言，我会说这再次归结为范围问题并保持干燥。 如果每次从newBuy返回数据，您必须调用sendMessage并且您在buy-service有数据来填充消息，那么您的服务应该一起工作。 他们这样做很好，毕竟你毫无疑问地以一种将其与发送消息之外的任何依赖性分离的方式编写message-service 。 因此，如果buy-service以类似的方式编写，它可以将其拉入并利用它。

考虑到上述情况，选项1因此似乎重复了每次调用购买服务时需要运行的功能。 出于这个原因，我会避免它，以防将来你想要扩展的东西，因为你的应用程序应该更容易推理，如果不依赖的功能不在各个地方复制。 相反，你会看看newBuy并看到它接收它的数据，它调用sendMessage ，因此更新很简单，逻辑清晰。

---

为了提供更多的上下文，我希望运行以下各个阶段：

组件导入购买服务并调用： newBuy() 调用newBuy()应该返回组件的Promise 购买服务导入消息服务 购买服务获取数据，即newBuy调用getMoney和getRecentBuys 。 以上两者都返回一个Promise ，现在你使用Promise.all等待2个端点解析并传回他们的数据。

关于解决newBuy Promise.all ：

getMoney返回数据： 购买服务将钱发送到vuex模块商店 如果您在此商店中有各种类型的数据，则可以将钱存储在vuex模块中。 这将有助于使其状态，行动等更容易使用 购买服务调用消息服务发送新消息： sendMessage() 购买服务解决了它的承诺 通过最近的购买作为有效载荷 在组件上解析Promise ，该组件现在使用有效负载更新其本地数据

拒绝newBuy Promise.all ：

购买服务拒绝其承诺 传递空的有效负载或消息 将错误发送到vuex商店 组件拒绝承诺 ，因此组件知道不更新其本地数据

In short, based on your situation: option 2

For me if there is no need for a state to be shared globally then all you are doing is polluting vuex's states by writing everything to it.

If for instance you had 10 components that functioned like the buy component, and each of those pulled an individual state only they needed from your vuex store, then you will be making the vuex store harder to reason about.

Furthermore if you start attaching actions and mutations for those states, then you'll likely need to build modules for each of the 10 components, again obscuring your state and logic.

Therefore in this instance option 2 seems a far better way to go if you are sure you won't need the state you retrieve elsewhere. You seem to have a pretty good grasp on why you would use vuex so that puts you in good stead. I would say that half the work with larger applications is in the planning. Therefore if you can map out how your app will function and see before you build where the connections need to be, and in turn where a components data is completely isolated, you should be able to quickly make those decisions on what you do and don't push to vuex.

In terms of the choice between option 1 & 2 I would say this again comes down to a question of scope and keeping things DRY. If every time you are returned data from newBuy you have to call sendMessage and you have the data in buy-service to populate the message, then your services should work together. It's fine that they do so, after all you are no doubt writing the message-service in a manner that decouples it from any dependancies outside those for sending messages. Therefore if the buy-service is written in a similar fashion it can pull that in and utilise it.

With the above in mind Option 1 therefore appears to be duplicating a function which would need to be run every time the buy service is called. For that reason I would avoid it in case in the future you want to expand things, as your app should be far easier to reason about if dependant functions are not replicated in various places. Instead you would look at newBuy and see on it receiving its data, it calls sendMessage and therefore updating is simple and the logic is clear.

---

To provide a little more context, I'd look to run the various stages like below:

The component imports the buy service and calls: newBuy() Calling newBuy() should return a Promise to the component The buy service imports the message service The buy service fetches the data, i.e. newBuy calls getMoney and getRecentBuys. Both of the above return a Promise, now you use Promise.all to wait for the 2 endpoints to resolve and pass back their data.

On resolving of the newBuy Promise.all:

getMoney returned data: the buy service dispatches the money to vuex modules store The money store could be held within a vuex module if you have various types of data within this store. It would help make its state, actions etc.. easier to work with The buy service calls the message service to send a new message: sendMessage() The buy service resolves its Promise pass the recent buys as the payload Promise is resolved on the component which now updates its local data with the payload

On rejecting of the newBuy Promise.all:

The buy service rejects its Promise pass an empty payload or message dispatch error to vuex store Promise is rejected on the component so component knows not to update its local data