使用中继进行数据获取

React在前端迎来了一个新时代。 它是由Facebook发布的，已迅速成为许多技术公司在生产中使用的流行库。 在本文中，我们将讨论一个称为Relay的新的补充性React框架。

React中的数据获取问题

随着React的普及，使用React构建的项目的规模和复杂性也随之增加。 React主要是一个视图层库。 这导致一些团队在构建需要不同基础结构的项目时遇到未知领域或限制。 在这些不断增长的痛苦中，Facebook一直积极提供支持和指导。

助焊剂

事件处理是使用React的开发人员的早期成长中的痛苦之一。 Facebook通过发布Flux来解决此问题，Flux是一种抽象模式，鼓励单向数据流处理React中的事件。

我假定对Flux有一定的了解，因此在本文中将不讨论它的详细信息。 如果您不熟悉此主题，则可以阅读Sandeep Panda的这篇文章，或浏览有关Flux的页面 。

Flux将React生态系统提升到了一个新的高度。 随着开发人员开始更加熟悉Flux，出现了一些问题。 Flux对于将数据作为应用程序状态进行管理一直非常有用，但是将初始状态填充到应用程序中一直是造成冲突的根源。

Flux的数据初始化面临一些挑战。 商店会呼叫服务器并自行填充吗？ 我们是否使用调度员的补水方法？ 我们是否在服务器上调用一堆动作来填充商店？ 我们如何异步执行此操作，并在返回响应之前将所有数据加载到同构应用程序中的服务器上？

什么是中继？

Relay是Facebook发布的新的React Data提取框架。 Relay旨在为所有这些数据获取问题提供清晰的解决方案。

中继有几个主要卖点：

• 声明式：这也是React的主要功能。 中继利用声明性代码样式定义来定义数据依赖性，这与定义视图组件的方式非常相似。 与传统的命令式数据获取API相比，这是令人耳目一新的变化。

• 并置：数据依赖项定义与组件定义同时存在，这使得推断UI组件需要呈现哪些数据变得更加容易。 这使得对项目代码进行故障排除变得容易得多。 通过查看包含React组件定义的文件，可以很明显地看出它需要起作用的数据。

• 突变：突变使用户可以无缝修改对已订阅React视图的数据的修改，并且还可以对数据持久层进行这些修改。

继电器vs助焊剂

Flux是一个抽象的想法，而Relay是受该想法启发的实现。 中继基于Flux的概念构建，具有与调度程序，操作和存储相同的概念，但是它们的表示形式有所不同。 中继具有一个称为“高阶组件”的新概念，我们将在本文的其余部分中对该主题进行扩展。

在这一阶段，目前尚不清楚Relay是否将替换现有Flux实现或与之实现一致。 例如，流行的Flux实现Redux也利用了“高阶组件”。 尝试同时使用Redux和Relay将导致在框架上绑定到UI组件的冲突。 目前， 有关Redux与Relay的关系正在进行讨论 。

高阶组件

高阶组件或HOC的定义方式与常规React组件相同。 HOC包装子UI组件。 HOC将执行其查询，然后呈现子UI组件，并将查询数据作为prop传入。 现在，通量流由HOC管理，后者将充当调度程序。 它具有setQueryParams()类的方法，可以视为Flux操作。 调用setQueryParams()会触发Flux流。 HOC中定义的查询将更新，获取新数据，并将数据保留在HOC中。 通过保留此数据，HOC充当Flux存储。

以下是ProfilePicture组件和免费HOC的简化示例。 想象一下，我们已经定义了ProfilePicture来渲染整个项目中的用户头像。 我们需要获取数据以显示用户头像。 然后，我们创建一个中继HOC，以从数据库中查询用户个人资料图片。 HOC将此查询数据传递到子ProfilePicture组件：

class ProfilePicture extends React.Component {
  // A standard Profile Picture component
}

// This is our Higher Order Component. It fetches the data to pass
// as props to Profile Picture
module.exports = Relay.createContainer(ProfilePicture, {
  fragments: {
    user: () => Relay.QL`
      fragment on User {
        profilePicture(size: $size) {
          uri,
        },
      }
    `,
  },
});

然后，我们的ProfilePicture组件将获得一些新的本地函数作为道具。 本质上，这就是继电器触发磁通流量的方式。 该组件调用这些Relay属性，这等效于Flux动作调用。 这导致中继获取请求的最新数据。 完成后，它将填充其内部存储，并将其作为道具传递给HOC的子视图组件。

GraphQL

上面的示例可能看起来有些奇怪，尤其是这部分：

Relay.QL`
      fragment on User {
        profilePicture(size: $size) {
          uri,
        },
      }
    `,

Relay背后的许多魔力都由GraphQL提供支持。 GraphQL是Facebook的一种新查询语言，专门用于对图形数据结构进行操作。 深入讨论GraphQL不在本文讨论范围之内，但是您可以通过阅读涵盖该问题的Relay文档来加深本主题 。 开箱即用，将无法设置现有项目来使用GraphQL。 建议开始使用Relay的首要步骤是：

1. 创建一个GraphQL模式
2. 创建一个GraphQL服务器

应当指出，将现有项目转换为GraphQL模式并设置或修改现有服务器使其对GraphQL友好可能需要大量工作。 从头开始项目时，立即使用Relay可能更有意义。 Facebook提供了一个Relay Starter Kit ，对于在新项目中使用Relay和GraphQL进行启动和运行来说，这似乎是一个很好的解决方案。

没有GraphQL的继电器

由于设置GraphQL所需的所有额外开销，Facebook的Relay可能不是现有项目的正确工具。 幸运的是，那里还有另一个受中继启发的库，该库可能更适合这些项目，称为反应传输。 react-transmit是一个开源项目，旨在成为“基于Promises而不是GraphQL的基于中继的库”。

如果我们从上面更新配置文件示例以使用react-trasmit那么我们将具有以下代码：

// Import Transmit
import Transmit from "react-transmit";

class ProfilePicture extends React.Component {
  // A standard Profile Picture component
}

// This is our Higher Order Component. It fetches the data to pass
// as props to Profile Picture
Transmit.createContainer(ProfilePicture, {
  fragments: {
    user: (userId) => {
      return new Promise(function(resolve, reject) { 
          // Do some Ajax here and resolve the promise
      });
    }
  },
});

反应发送示例看起来与中继示例非常相似。 但是，在这种情况下， user片段现在是一个返回Promise而不是GraphQL查询的函数。

继电器的当前状态

Facebook已经发布了Relay的开源“技术预览” 。 他们在存储库中有一些很棒的示例，展示了如何使用Relay以及非常详细的文档部分 。

目前看来Relay不适合同构应用。 没有办法告诉Relay等待所有数据依赖项加载之后再呈现其子视图，这是服务器上需要的。 如果您有兴趣，目前正在进行有关Relay如何在服务器上工作的讨论 。 此刻，这是当前反应传输更适合的模式。

至于Relay的未来，其路线图旨在尽快提供一些关键功能：

• 其他数据存储类型的适配器，因此对GraphQL没有硬性依赖。
• 更好的同构支持 ，如前所述。

结论

在本文中，我们讨论了一种称为Relay的新React补充框架。 中继基于Flux的某些相同概念构建，并由GraphQL提供支持。 如前所述，对于现有项目而言，Relay可能不是一个好的选择。 但是，该框架是一个相当新的框架，我希望它在每个发行版中都将变得越来越好。

现在轮到你了。 你知道中继吗？ 您是否曾经在其中一个项目中采用它？

From: https://www.sitepoint.com/react-data-fetching-with-relay/