将vuex状态与服务器同步的推荐策略

Question

想象一下这个简单的案例.您有一个Vue JS应用程序,用户可以在其中创建任务列表并对其进行排序.这些列表应由服务器存储在数据库中.让我们假设我们拥有ListComponent大部分用户体验.

我的问题是,我应该使用哪种模式来处理前端和后端数据同步？

A)浏览vuex:将活动列表(显示,编辑或创建的列表)存储在vuex中store.在ListComponent将改变store,并随后,在列表中所做的更改将通过API发送到后端.

B)直接转到服务器:ListComponent每次显示,编辑或创建列表时,直接从服务器读取和写入.

如果遵循A,商店应该采用哪种架构？我应该如何以及何时进行同步？如何跟踪已更改的内容和未更改的内容？

Answer 1

两者都可以正确,具体取决于您的使用案例.我目前正在构建的应用程序使用两者.

何时使用B:直接转到服务器 如果数据非常重要,请使用B. 在这种情况下,您可能希望直接转到服务器并提供响应以验证它是否已提交给数据库.我们将此过程用于管理员类型更改.请注意,您还可以在服务器响应后更新Vuex,并仍使用Vuex来提供数据.

何时使用A:Go through Vuex 如果您需要更快的体验,请使用A,因为无需等待服务器.在实际保存之前,您必须乐观地显示更改.另一个好处是您可以将Vuex同步到localStorage.我们将此用于用于自定义视图的用户首选项.它是一个糟糕的经验,减慢页面只是等待获取它们.

如何使用A:浏览Vuex 有几种方法可以做到这一点.这是一种模式:

1. 从组件发送Vuex Action 1
2. 从更新状态的Action提交V​​uex Mutation - 这是一个乐观的更新,因为您假设它将通过
3. 从Action 1中调度另一个Vuex Action 2 - 这假设您将在多个Actions中重用此Action,否则它们都可以进入Action 1
4. 操作2将数据发送到服务器
5. 在承诺返回时,Action 2提交变更以更新Vuex状态
6. 变异需要处理任何差异(或错误)

计算Vuex的成本

就像您的评论所示,如果您需要使用Vuex,那么计算成本是件好事,因为它确实会增加很多开销和复杂性.理想情况是以包含与一种类型数据(例如"列表")的所有交互的方式编写组件,这样您就不必通过Vuex共享状态.