时间戳

首页 > 解决方案 > Vue 填充组件的方法

ajax - Vue 填充组件的方法

问题描述

我似乎找不到任何信息，最好将数据放入组件中。为了定义问题，假设我们user在数据库中有一个表，这个表有一个 ID，可能有 30 个字段，其中包含有关用户的详细信息。

现在，如果我想创建一个显示许多用户详细信息列表的 Vue 组件，我们只需调用它<user-details>。要在页面上显示此内容，您会：

1) 调用数据库来获取你想要显示的所有用户并获取他们的 ID，然后执行 for 循环<user-details id="xxx">并让 Vue 对某些 API 进行 ajax 调用并获取详细信息？

2) 或者，使用<user-details id="xxx" name="user name" ...>具有 30 多个字段的内联版本？

3）或者，这个用户列表有一些特定的Vue组件，也许是没有验证电子邮件或其他东西的用户，然后<users-not-validated>使用ajax？

我看到的问题是，在案例 1 中，您已经为 ID 调用了数据库，然后使用几乎相同的 SQL 再次使用 ajax 调用数据库。

在情况 2 中，每次使用该组件时都填写这么多字段很烦人。

在第 3 种情况下，您最终会得到大量组件......

你如何处理这个问题？

标签： ajaxvue.jsvue-component

解决方案

您不会找到此类信息，因为它与 Vue 无关。Vue 不关心你用它做什么以及你如何构建你的数据。它旨在让你做任何你想做的事情。

就像它不关心你的文件夹结构是什么样子（因为它的核心是渲染一个 DOM 元素），它也不关心你如何组织你的 API，你如何构建你的应用程序、您的页面甚至您的组件。

显然，拥有如此多的自由并不总是一件好事。如果你环顾四周，你会发现专业使用 Vue 的人已经接受了某些模式/结构，这些模式/结构允许更好的代码重用和更大的灵活性。Nuxt 就是一个很好的例子。

对于刚开始使用 Vue 的任何人，我建议尽快尝试使用 Nuxt，即使它对他们的小项目来说太过分了，因为他们可能会选择一些好的模式。

谈到你的具体问题，就数据 API 架构而言，你总是要问自己：底层原理是什么？

基本原则是使您的应用程序尽可能快。为了做到这一点，理想情况下，您希望准确获取要显示的数据量，但不要更多。所以：

  • 在获取相同数据时，如果可以选择，请始终尝试降低请求数。您不希望列表中的每个项目在呈现时都启动对服务器的调用。对整个列表进行一次调用（仅获取您在列表视图中显示的内容）并在用户请求时调用详细信息（按详细信息按钮）。
  • 调整您的分页以适应您可以在屏幕上显示的项目数量，以及加载页面所需的时间。如果花费的时间太长，请降低 pageSize 并允许您的项目更多填充。如果您考虑一下，大多数人更喜欢页面上项目较少（以及大量填充项目）的快速应用程序，而不是一个需要几秒钟来加载每个页面并显示项目如此破碎以至于难以点击/点击或难以遵循的应用程序在列表中而不丢失行。

但是，您必须对这些准则持保留态度。在绝大多数情况下，一次调用获取完整数据对用户体验几乎没有影响。很多时候，延迟与服务器冷启动有关（第一次调用服务器需要更长的时间，因为它需要“唤醒它” - 但所有相同类型的后续调用都更快）、未优化的图像或网络不佳连接性（例如，无论您是仅收到名称还是完整的详细信息列表，它都无法正常工作）。

要记住的另一个方面是一次获取所有数据是一种权衡。您确实会得到较慢的初始调用，但之后您可以在列表视图和详细视图之间进行无缝动画，因为数据已经被获取，不需要更多的加载。如果您优雅地处理加载状态，那么在许多情况下它都是一个可行的选择。

最后但并非最不重要的一点是，您的第二点的缺点不存在。您始终可以一次性绑定所有细节：

<user-details v-bind="user" />

相当于

<user-details :id="user.id" :name="user.name" :age="user.age" ... />

给你一个非常基本的例子，你的用例的典型标记是：

<div v-if="isLoadingUsers" />
<user-list v-else :users="users">
   <user-list-item v-for="(user, key) in users"
                   :key="key"
                   v-bind="user" 
                   @click="selectedUser = user" />
</user-list>
<user-details-modal v-bind="selectedUser" />

这显然是一种简化，您可能会选择没有用户详细信息模式，但transform列表项很酷，使其增长并显示更多详细信息，等等......

如有疑问，请简化。例如，仅显示一个选定项目的详细信息（并在选择另一个项目时关闭它）将立即解决许多 UI 问题。

至于最后一个问题：对于不同的状态是否有不同的组件，答案应该来自回答一个不同的问题：你应该让你的组件得到多大？上限通常被认为是 300 行左右，尽管我知道开发人员不会超过 200 行，而其他人在组件中有 500 多行也没有问题）。

当它变得太大时，您应该提取其中的一部分（假设用户未验证的功能到子组件中）并最终在<user-detail>组件中使用它：

<user-detail>
  ... common details (title, description, etc...)

  <div v-if="user.isValidated">
     ...normal case
  </div>
  <user-not-validated v-bind="user" v-else />

  ... common functionality (action bar, etc...)
</user-detail>

但是，这些是组件的子<user-detail>组件，它们被提取以帮助您保持代码的组织性。他们不应该<user-detail>全部替换。同样，您可以提取用户详细信息的页眉或页脚组件，只要有意义。您的目标应该是保持代码整洁有序。遵循任何对你更有意义的原则。

最后，如果我在做出代码架构决策时必须挑出一个有用的指导方针，那肯定是 DRY 原则。如果您最终不必在同一个应用程序的多个位置编写相同的代码，那么您做对了。

希望你会发现上面的一些有用的东西。

推荐阅读