3

Most examples I come across seem to always fetch the data from URL.

But on server side, would it not make sense to fetch data directly from the database ?

So in the action creator it would look something like:

if(typeof document !== 'undefined')
  fetch("url/posts").then(response => dispatch(receivedPosts(response))
else
  db.select("posts").then(response => dispatch(receivedPosts(response))

What are the Pros and Cons of this method relative to other data-fetching methods ?

4

1 回答 1

2

大多数 React/Redux 应用程序都构建在 API 开发和 UI 开发分离的环境中。通常，这些相同的 API 为移动应用程序和其他桌面应用程序提供动力，因此您展示的直接数据库查询将无法用于服务器端渲染。

在您的情况下，您似乎使用单个代码库构建全栈应用程序。这没有什么问题，但是您可能应该考虑一些事情。首先是建立应用程序的可能生命周期。一个有趣的小项目是为了更多地了解堆栈，一家初创公司竞相获得和 MVP 上市，以及一个大型企业构建一个必须向外扩展的平台，这之间有很大的不同。这些场景中的每一个都可能导致您对如何设计应用程序的层级有不同的考虑。与您的工作相关的一个重要问题是其他应用程序/平台是否可能需要访问这些相同的数据，以及不同的团队最终是否可能会维护后端和前端。使用 node 和 mongo 它' s 很容易创建 API 端点，这些端点最初为你的 React 应用程序提供服务，但以后可以被原生 IOS 应用程序使用。您还将在应用程序的维护和增强中获得关注点分离的好处。当您将数据访问和 UI 逻辑完全分开时，调试通常会更容易，因为您可以使用 postman 之类的东西直接调用您的 API 来确定它们是否提供了正确的数据。

在您的情况下，似乎可能已经从 /posts 提供 API 数据，因此您可能会获得我提到的所有这些好处，但仍然可以通过绕过 API 来跳过网络跃点，如您的代码片段所示。这将在服务器渲染中减少一个故障点并且速度会更快一些，但您可能不会获得太多速度，并且如果您的 API 有网络问题，它们会立即出现在客户端应用程序，因此好处不会太大。

我个人只会在 React 应用程序中进行 fetch 调用，并将我所有的数据访问/API 逻辑分离出来，这样将来将后端和前端移动到两个单独的存储库不会太痛苦。这将使该应用程序在未来的潜在增长中处于有利地位。关注点分离的好处超过了任何轻微的性能提升。如果您遇到页面加载缓慢的问题，那么可能有很多地方需要调整，通常从 db 查询本身开始。

于 2016-08-08T05:18:38.253 回答