有没有推荐的Vue JS应用API和Vuex设计模式
Is there a recommened VueJS application API and Vuex design pattern
我和我的团队正在研究中~大型应用程序的开端。这是一个 Vue 2 客户端呈现的应用程序，具有 asp.net 核心后端。客户端将用于管理数以万计的项目，他们的 status.The 应用程序处于早期阶段，我们一直在考虑重新构建现有客户端商店的方法。
由于我们都是新手而且都是自学成才，所以我们不确定 Vue 应用程序中数据管理的最佳模式是什么。
在 VueJS 应用程序中是否有推荐的数据管理模式？
我们目前的模式是这样的：
| |
| +-----------+ |
| | | | +-----------+ +-----------+ +------------+
| | API |---->| | | | | |
| | | | | Router |---->| Vuex |---->| Views/ |
| +-----------+ | | | | |<----| Components |
| ^ | ^ | | | | | | |
| | | | | +-----------+ +-----------+ +------------+
| | | | |Vue |
| | | | +---------------------------|-------------------------
| | | | |
|Client| -----------------------------------
+----|-|---------------------------------------------
| |
+---------|-|------
|Backend | v
| +----------+
| | |
| DB |
| |
| |
+----------+
我们有一个 API 控制器，其中包含我们所有的 API 端点。加载应用程序时，在路由器的 beforeEnter 函数中，我们获取所有数据，然后将其提交到 Vuex 存储。然后，当用户使用应用程序 (adding/deleting/editing) 项目时，商店会被修改，然后 Vuex 调用 API 控制器并将数据发送到后端。
从我们所做的研究来看，关于谁应该调用 API 以及 Vuex 应该存储哪种数据的意见似乎是混杂的。一些博客和课程说 Vuex 是管理 API 的方式，但受人尊敬的 Vue 社区成员之间的论坛讨论却另有说法。然而，主要问题是 Vue 快速、不断变化的环境文章和 2018/19 年的讨论并不真正适用于今天的 Vue。
我们目前的想法不是从路由器提交到 Vuex，而是将数据从路由器传递到视图，然后让视图提交到商店。 Views/components 也会调用帖子而不是 Vuex。这将限制商店的责任。
我们也研究了使用 Nuxt.js 的可能性，但他们的文档没有提供关于 store/API 管理的严格指导。
我觉得this image from vuex website很好的解释了vuex每一个元素的关注点。 Actions 调用 API，然后是一个 mutation，用于提交收到的响应以更新应用程序的状态。 Vue 组件通过 getter 读取状态。当操作提交状态更新时，getter 会更新它们的值，并且您的组件会呈现更新后的数据。如果你有一个 vue 组件需要来自你的 API 的一些数据来渲染，你可以从导航守卫调度一个或多个动作，比如 beforeEnter 或 beforeRouteEnter 来加载或更新应用程序状态
TL;DR: You need mix of multiple things when building large-scale Vue.js application (or SPA application) in general.
没有固定的推荐模式可以做到这一点。正确答案总是 - 这取决于。
以下是一些有用的指南：
图层
一般来说，有两种方式——水平分层和垂直分层。水平分层，系统分为
层
App Level Component
<-- Multiple Views (pages)
<-- Business Logic Components
<-- Re-usable lower order components
and API (Fetch/XHR/Websockets)
通常，业务逻辑组件是一次性使用 API 层模块。这些基本上是一堆模块，包含各种 API 调用和规范化它们的响应。
这看起来很干净，但如果组件太多，很快就会变得笨拙，因为所有内容都在平面文件夹中。
除了API层，其他层一般都是垂直（按业务行为）拆分成模块，所有关联的组件和辅助代码都保存在该模块或相关的子模块中。比如在电商软件中-拆分为账户、订单、支付、目录等
然而，垂直分层只有在你真正拥有大规模应用程序时才有用，否则，简单的水平分层就足够了。
申请状态
这就是事情变得棘手的地方。随着应用程序的发展，这是一个持续的过程。这里要练习的是 Global State 和 Local State 的组成部分。想象一个带有铃铛图标的应用程序来指示未读消息，并且同一页面在底部某处有一种读取消息的方式（如 Facebook/LinkedIn），其中必须同步和维护状态。
这是全局状态的一个例子，因此它可以在一些顶级共同祖先或更好的外部数据存储中维护，如 Redux 或 Vuex 。两者都同样好。 通常只有这样的全局和共享状态才应该建模到显式状态存储中。另一个例子是登录用户的详细信息，可以使用 re
将特定状态列入商店的另一个标准是当您需要时间旅行（撤消和重做）功能或想要为绘图应用、游戏等应用保持本地持久性时。
路由和状态管理
与全局状态一起，路由是应用程序的另一个顶级关注点。首先出现的始终是全局存储，因为路由决策（守卫、预取等）可能会使用存储中的全局数据。因此，您将始终先初始化存储，然后在需要时将其与路由器一起使用。
API层
将所有 API 代码放在一起，因为它可以快速帮助识别重复项（如果有）。 API 层应尽可能转储，主要处理数据规范化、解析、解码、调整 camel/snake 大小写等。API 层不应直接从路由器或全局状态存储访问信息.如果它需要什么，应该由调用者传递给它。
但是，如果您同时使用 GraphQL 和订阅，情况就会有所不同。在这种情况下，它会更加了解上下文，应该这样设计。
组件设计
明确区分高阶和低阶组件。低阶组件是可重用的，例如 Button、Calendar、DatePicker、Dropdown 等。它们应该不了解应用程序及其业务逻辑。它就像您拥有一个可以在任何 Vue.js 应用程序中使用的迷你组件库。
高阶组件是应用程序的主要魔法所在。这些组件将从 router/vuex/api 等多个来源获取数据。这些组件又不是扁平的，通常分为自己的层。
只应允许最顶层的组件访问路由器，并应为其子组件提供数据。授权将分散在组件层次结构中。
有几个链接可以进一步帮助您：
我和我的团队正在研究中~大型应用程序的开端。这是一个 Vue 2 客户端呈现的应用程序，具有 asp.net 核心后端。客户端将用于管理数以万计的项目，他们的 status.The 应用程序处于早期阶段，我们一直在考虑重新构建现有客户端商店的方法。
由于我们都是新手而且都是自学成才，所以我们不确定 Vue 应用程序中数据管理的最佳模式是什么。
在 VueJS 应用程序中是否有推荐的数据管理模式？
我们目前的模式是这样的：
| |
| +-----------+ |
| | | | +-----------+ +-----------+ +------------+
| | API |---->| | | | | |
| | | | | Router |---->| Vuex |---->| Views/ |
| +-----------+ | | | | |<----| Components |
| ^ | ^ | | | | | | |
| | | | | +-----------+ +-----------+ +------------+
| | | | |Vue |
| | | | +---------------------------|-------------------------
| | | | |
|Client| -----------------------------------
+----|-|---------------------------------------------
| |
+---------|-|------
|Backend | v
| +----------+
| | |
| DB |
| |
| |
+----------+
我们有一个 API 控制器，其中包含我们所有的 API 端点。加载应用程序时，在路由器的 beforeEnter 函数中，我们获取所有数据，然后将其提交到 Vuex 存储。然后，当用户使用应用程序 (adding/deleting/editing) 项目时，商店会被修改，然后 Vuex 调用 API 控制器并将数据发送到后端。
从我们所做的研究来看，关于谁应该调用 API 以及 Vuex 应该存储哪种数据的意见似乎是混杂的。一些博客和课程说 Vuex 是管理 API 的方式，但受人尊敬的 Vue 社区成员之间的论坛讨论却另有说法。然而，主要问题是 Vue 快速、不断变化的环境文章和 2018/19 年的讨论并不真正适用于今天的 Vue。
我们目前的想法不是从路由器提交到 Vuex，而是将数据从路由器传递到视图，然后让视图提交到商店。 Views/components 也会调用帖子而不是 Vuex。这将限制商店的责任。
我们也研究了使用 Nuxt.js 的可能性，但他们的文档没有提供关于 store/API 管理的严格指导。
我觉得this image from vuex website很好的解释了vuex每一个元素的关注点。 Actions 调用 API，然后是一个 mutation，用于提交收到的响应以更新应用程序的状态。 Vue 组件通过 getter 读取状态。当操作提交状态更新时，getter 会更新它们的值，并且您的组件会呈现更新后的数据。如果你有一个 vue 组件需要来自你的 API 的一些数据来渲染，你可以从导航守卫调度一个或多个动作，比如 beforeEnter 或 beforeRouteEnter 来加载或更新应用程序状态
TL;DR: You need mix of multiple things when building large-scale Vue.js application (or SPA application) in general.
没有固定的推荐模式可以做到这一点。正确答案总是 - 这取决于。
以下是一些有用的指南：
图层
一般来说，有两种方式——水平分层和垂直分层。水平分层，系统分为
层App Level Component
<-- Multiple Views (pages)
<-- Business Logic Components
<-- Re-usable lower order components
and API (Fetch/XHR/Websockets)
通常，业务逻辑组件是一次性使用 API 层模块。这些基本上是一堆模块，包含各种 API 调用和规范化它们的响应。
这看起来很干净，但如果组件太多，很快就会变得笨拙，因为所有内容都在平面文件夹中。
除了API层，其他层一般都是垂直（按业务行为）拆分成模块，所有关联的组件和辅助代码都保存在该模块或相关的子模块中。比如在电商软件中-拆分为账户、订单、支付、目录等
然而，垂直分层只有在你真正拥有大规模应用程序时才有用，否则，简单的水平分层就足够了。
申请状态
这就是事情变得棘手的地方。随着应用程序的发展，这是一个持续的过程。这里要练习的是 Global State 和 Local State 的组成部分。想象一个带有铃铛图标的应用程序来指示未读消息，并且同一页面在底部某处有一种读取消息的方式（如 Facebook/LinkedIn），其中必须同步和维护状态。
这是全局状态的一个例子，因此它可以在一些顶级共同祖先或更好的外部数据存储中维护，如 Redux 或 Vuex 。两者都同样好。 通常只有这样的全局和共享状态才应该建模到显式状态存储中。另一个例子是登录用户的详细信息，可以使用 re
将特定状态列入商店的另一个标准是当您需要时间旅行（撤消和重做）功能或想要为绘图应用、游戏等应用保持本地持久性时。
路由和状态管理
与全局状态一起，路由是应用程序的另一个顶级关注点。首先出现的始终是全局存储，因为路由决策（守卫、预取等）可能会使用存储中的全局数据。因此，您将始终先初始化存储，然后在需要时将其与路由器一起使用。
API层
将所有 API 代码放在一起，因为它可以快速帮助识别重复项（如果有）。 API 层应尽可能转储，主要处理数据规范化、解析、解码、调整 camel/snake 大小写等。API 层不应直接从路由器或全局状态存储访问信息.如果它需要什么，应该由调用者传递给它。
但是，如果您同时使用 GraphQL 和订阅，情况就会有所不同。在这种情况下，它会更加了解上下文，应该这样设计。
组件设计
明确区分高阶和低阶组件。低阶组件是可重用的，例如 Button、Calendar、DatePicker、Dropdown 等。它们应该不了解应用程序及其业务逻辑。它就像您拥有一个可以在任何 Vue.js 应用程序中使用的迷你组件库。
高阶组件是应用程序的主要魔法所在。这些组件将从 router/vuex/api 等多个来源获取数据。这些组件又不是扁平的，通常分为自己的层。
只应允许最顶层的组件访问路由器，并应为其子组件提供数据。授权将分散在组件层次结构中。
有几个链接可以进一步帮助您：