1

我已经阅读了材料，但我仍然不明白。

此示例路线出现：

var profileRoute = {
  queries: {
    // Routes declare queries using functions that return a query root. Relay
    // will automatically compose the `user` fragment from the Relay container
    // paired with this route on a Relay.RootContainer
    X: () => Relay.QL`
      # In Relay, the GraphQL query name can be optionally omitted.
      query { user(id: $userID) }
    `,
  },
  params: {
    // This `userID` parameter will populate the `$userID` variable above.
    userID: '123',
  },
  // Routes must also define a string name.
  name: 'ProfileRoute',
};

（我故意替换user为X上面对生成的 GraphQL 查询没有影响的地方，以确保它对 graphql 组合没有影响）

它将与此容器配对：

module.exports = Relay.createContainer(ProfilePicture, {
  // Specify the initial value of the `$size` variable.
  initialVariables: {
    size: 32
  },
  // For each of the props that depend on server data, we define a corresponding
  // key in `fragments`. Here, the component expects server data to populate the
  // `X` prop, so we'll specify the fragment from above as `fragments.X`.
  fragments: {
    X: () => Relay.QL`
      fragment on User {
        profilePhoto(size: $size) {
          uri,
        },
      }
    `,
  },
});

这可能会组成如下内容：

query {
  user(id: $userID) {
    profilePhoto(size: $size) {
      uri
    }
  }
}

但这里的逻辑是什么？也许它User从片段中获取类型，然后寻找一种方法来获取该类型作为查询中匹配内容的直接后代？也就是说，它通过编译 GraphQL 知道在query { user(id: $userID) { X } }X 中标记了可以找到用户类型的位置。

到目前为止，我看到的唯一示例在路由器中有一个非常简单的线性查询。可以更复杂吗？如果您进行的查询在两个不同的方向上进行并最终接近两个不同的用户对象源会发生什么？它怎么会知道你想要哪个？我认为这样的查询是不允许的。我还假设它在这些查询中查找的唯一位置是最深点，因此如果您的路由器查询类似于query { user(id: "52") { bestFriend } }bestFriend 也是用户的位置，它将给您 bestFriend 而不是用户 52。

它甚至允许有一个以上深度的查询吗？我试过了，我得到了这个错误：

不变违规：Relay.QL：预期查询user为空。例如，使用node(id: $id)，而不是node(id: $id) { ... }

也许路线比我想象的更简单？也许你能做的只有一个层次的深度？

4

1 回答 1

1

构图比你想象的要简单。查询只能有一个级别的深度，并且组合组件上的同名片段（例如在这种情况下X）本质上是展开（...fragment）到其中。

Relay 理论上可以支持任意复杂的查询，但现有的解决方案到目前为止已经足够了。这是因为任意复杂的查询可以分解为简单查询和新的顶级组件。

我还假设它在这些查询中的唯一位置是最深点 [...]

不过，这是一个巧妙的想法。

于 2015-10-14T01:46:17.797 回答