Root Container #Facebook Relay文档翻译#

本文深入解析了Relay.RootContainer组件在构建完整GraphQL查询中的关键角色,如何利用它与Relay.Route和Relay.Container共同作用,实现从服务器端获取数据的过程,并详细介绍了如何通过设置回调函数来控制渲染行为,包括加载状态、数据获取后的渲染以及错误处理。

原文地址
上一篇 Routes
Relay文档翻译目录

So far, we’ve covered two pieces that each contribute to declaring data:
到目前为止,我们已经讲了两个重要的部分,都是用来声明数据的:

  • Relay.Route lets us declare query roots.声明query roots
  • Relay.Container lets components declare fragments. 让components声明fragments

To use these pieces to construct a full-fledged GraphQL query that we can send to the server to fetch data, we need to use the Relay.RootContainer.
想使用这两部分去构建一个完整的可以从服务器端获取数据的GraphQL query,我们还需要Relay.RootContainer

Component and Route

Relay.RootContainer is a React component that, given a Component and a route, attempts to fulfill the data required in order to render an instance of Component.
Relay.RootContainer是一个React component,可以接收一个component和一个route作为props,去获取所需要的数据并渲染这个component的实例。

React.render(
  <Relay.RootContainer
    Component={ProfilePicture}
    route={profileRoute}
  />,
  container
);

When the Relay.RootContainer above is rendered, Relay will construct a query and send it to the GraphQL server. As soon as all required data has been fetched, ProfilePicture will be rendered. Props with fragments will contain data that was fetched from the server.
当上面的Relay.RootContainer被渲染时,Relay将构建一个query发送给GraphQL server。一旦数据都获取到了,ProfilePicture将被渲染。其中与fragments对应的props中将包含从服务器端获取来的数据。

If either Component or route ever changes, Relay.RootContainer will immediately start attempting to fulfill the new data requirements.
如果 Componentroute改变了的话, Relay.RootContainer会立刻尝试满足新的数据需求。

Render Callbacks

Relay.RootContainer accepts three optional callbacks as props that give us more fine-grained control over the render behavior.
Relay.RootContainer还可以接收三个可选的回调作为props,在渲染的过程中给我们更细的颗粒度控制。

renderLoading

Relay.RootContainer renders the loading state whenever it cannot immediately fulfill data needed to render. This often happens on the initial render, but it can also happen if either Component or route changes.
Relay.RootContainer 在完全获取到所需的数据之前是有一个过程的。这经常发生在初始化或者Componentroute改变的时候。

By default, nothing is rendered while loading data for the initial render. If a previous set of Component and route were fulfilled and rendered, the default behavior is to continue rendering the previous view.
默认情况,在初始化加载数据的过程中不会显示什么。如果之前的Component and route已经被渲染过了,默认的行为是再加载新数据时继续显示原来的画面。

We can change this behavior by supplying the renderLoading prop:
我们可以通过renderLoading改变默认加载的行为:

<Relay.RootContainer
  Component={ProfilePicture}
  route={profileRoute}
  renderLoading={function() {
    return <div>Loading...</div>;
  }}
/>

This snippet configures Relay.RootContainer to render the “Loading…” text whenever it needs to fetch data.
它表示在数据加载时显示”Loading…”

A renderLoading callback can simulate the default behavior by returning undefined. Notice that this is different from a renderLoading callback that returns null, which would render nothing whenever data is loading, even if there was a previous view rendered.
renderLoading回调可以用返回undefined来模拟默认的行为。注意它与返回null是不同的,它将什么都不会显示,即便原本之前有视图被显示。

renderFetched

When all data necessary to render becomes available, Relay.RootContainer will render the supplied Component by default. However, we can change this behavior by supplying a callback to the renderFetched prop:
当所有需要的数据准备好时,Relay.RootContainer将默认渲染prop中的Component。但是我们可以通过renderFetched改变这一行为。

<Relay.RootContainer
  Component={ProfilePicture}
  route={profileRoute}
  renderFetched={function(data) {
    return (
      <ScrollView>
        <ProfilePicture {...data} />
      </ScrollView>
    );
  }}
/>

This snippet configures Relay.RootContainer to render ProfilePicture within a ScrollView component as soon as data is ready.
它将在数据准备好时,使ProfilePictureScrollView component中一起渲染。

The renderFetched callback is always called with a data argument, which is an object mapping from propName to query data. It is expected that the renderFetched callback renders the supplied Component with them (e.g. using the JSX spread attributes feature).
renderFetched回调通常有一个data参数,它是一个保存propName到查询数据映射的对象。用于把data传给被用来渲染的component

Note

Even though we have access to the data object in renderFetched, the actual data is intentionally opaque. This prevents the renderFetched from creating an implicit dependency on the fragments declared by Component.
尽管我们在renderFetched中有访问data对象的权利,实际的data是有意不透明的。它可以防止renderFetchedComponent声明的fragment上创建隐含的依赖关系。

renderFailure

If an error occurs that prevents Relay.RootContainer from fetching the data required for rendering Component, nothing will be rendered by default. Error handling behavior can be configured by supplying a callback to the renderFailure prop:
如果在Relay.RootContainer 获取数据并渲染的过程中发生了错误,默认情况下什么也不会被渲染出来。可以通过renderFailure来做错误处理。

<Relay.RootContainer
  Component={ProfilePicture}
  route={profileRoute}
  renderFailure={function(error, retry) {
    return (
      <div>
        <p>{error.message}</p>
        <p><button onClick={retry}>Retry?</button></p>
      </div>
    );
  }}
/>

The renderFailure callback is called with two arguments: an Error object and a function to retry the request. If the error was the result of a server error communicated in the server’s response, the response payload is available for inspection on error.source.
renderFailure的回调中可以使用两个参数,一个Error对象,一个retry函数。如果error是服务器端数据通讯返回的错误,可以通过error.source进一步查看错误原因。

Force Fetching

Like most of the Relay APIs, Relay.RootContainer attempts to resolve data using the client store before sending a request to the server. If we instead wanted to force a server request even if data is available on the client, we could use the forceFetch boolean prop.
像大多数Relay API一样,Relay.RootContainer在向服务器端发送请求之前,会先在客户端store中尝试获取数据。如果我们想强制其每次都去服务器端获取数据,不论本地是否有的话,我们可以用forceFetch

<Relay.RootContainer
  Component={ProfilePicture}
  route={profileRoute}
  forceFetch={true}
/>

When forceFetch is true, Relay.RootContainer will always send a request to the server. However, if all the data required to render is also available on the client, renderFetched may still be called before the server request completes.
forceFetch为真时,Relay.RootContainer将总是向服务器端发送请求。尽管如此,如果客户端已经有了所有的数据,renderFetched还是会在服务器端请求完成之前被回调到的。

<Relay.RootContainer
  Component={ProfilePicture}
  route={profileRoute}
  forceFetch={true}
  renderFetched={function(data, readyState) {
    var isRefreshing = readyState.stale;
    return (
      <ScrollView>
        <Spinner style={{display: isRefreshing ? 'block' : 'none' }}
        <ProfilePicture {...data} />
      </ScrollView>
    );
  }}
/>

When forceFetch is true and renderFetched is called as a result of available client data, renderFetched is called with a second argument that has a stale boolean property. The stale property is true if renderFetched is called before the forced server request completes.
forceFetch为真并且renderFetched被回调,它回调时还有第二个参数,其中包含了布尔类型stale。renderFetched在强制请求服务器数据全部返回以前,stale为真。

Ready State Change

Relay.RootContainer also supports the onReadyStateChange prop which lets us receive fine-grained events as they occur while fulfilling the data requirements.
Relay.RootContainer同样支持onReadyStateChangeprop。它给了我们在满足数据需求时更细粒度的事件控制。

Learn how to use this prop in the Ready State guide.
在接下来继续学习State

<think>我们有一个需求:将原有的#define宏定义修改为新的格式。 原有的格式示例:#define RELAY_I2C_OVI 0, 64, -1 新的格式要求:#define RELAY_SS "RELAY_SS" 注意:新的格式中,宏名称后面跟着一个字符串,字符串的内容就是宏名称本身(去掉前缀RELAY_,并且将后面的部分转换为大写?但观察示例,似乎就是原样输出宏名称,但是用双引号括起来)。 但是,观察新的格式示例:#define RELAY_SS "RELAY_SS" 这里实际上是将宏名称原样输出作为字符串。 因此,我们需要将每一行的#define后面的第一个单词(即宏名称)取出来,然后将其作为字符串放在双引号中。 例如: 原行:#define RELAY_I2C_OVI 0, 64, -1 转换后:#define RELAY_SS "RELAY_I2C_OVI" 但是注意,新格式中宏名称是RELAY_SS,而我们的目标是将所有的宏都改为RELAY_SS吗?显然不是,因为每个宏的名称不同。 然而,目标格式示例中写的是RELAY_SS,但根据要求,我们应该是将每个宏重新定义为一个字符串,字符串就是该宏原来的名称。 但是,目标格式示例中写的是: #define RELAY_SS "RELAY_SS" 这似乎是一个固定的模式:新的宏名称都是RELAY_SS?这显然不合理,因为这样会导致重复定义。 所以,我们需要重新理解需求:修改这段代码变成以下格式 #define RELAY_SS “RELAY_SS” 注意,这里RELAY_SS只是一个示例,并不是说所有宏都改成RELAY_SS。实际上,我们应该是将每个原有的宏定义,改为一个字符串定义,字符串的内容就是该宏的名称。 但是,我们注意到,原代码中每个宏的名称都是不同的,所以我们需要为每个宏生成一个新的定义,新的宏名称应该是什么?需求没有明确。 然而,观察示例输出格式,它只给出了一个例子:#define RELAY_SS "RELAY_SS",这里新的宏名称是RELAY_SS,而字符串也是"RELAY_SS"。 所以,我们可能需要将原有的每个宏都重新定义为一个新的宏,新的宏名称可能是固定的(比如RELAY_SS)?但是这样会导致重复定义,因为每个原来的宏都会被替换成同一个新的宏名称。 另一种理解:我们可能只是将原有的宏定义改为一个字符串常量,并且这个字符串常量的名称与原来的宏名称相同?但是这样也不对,因为原来的宏名称后面还有数字。 实际上,我们可能误解了需求。需求是“修改这段代码变成以下格式”,而格式是: #define RELAY_SS “RELAY_SS” 注意,这里RELAY_SS可能只是一个示例,我们需要将每个宏都按照这个模式转换,即: #define <原来的宏名称> "原来的宏名称" 例如: #define RELAY_I2C_OVI "RELAY_I2C_OVI" 这样,我们就将原来的带参数的宏定义,改成了一个不带参数的宏定义,其值是一个字符串,字符串内容就是宏名称。 因此,转换规则是: 提取原宏定义中的宏名称(即#define后面的第一个单词),然后将其重新定义为该名称的字符串形式。 所以,对于每一行,我们只需要保留宏名称,然后将其替换为: #define 宏名称 "宏名称" 注意:原代码中每行后面还有三个数字(或两个数字和一个负数),这些在新格式中都不需要了。 让我们开始转换: 原行:#define RELAY_I2C_OVI 0, 64, -1 转换后:#define RELAY_I2C_OVI "RELAY_I2C_OVI" 但是,注意原代码中有一行: #define RELAY_VDD_CTG_4 40. 104, -1 -> 这里有一个笔误,40后面是点号,应该是40, 104, -1?不过不管怎样,我们只关心宏名称。 所以,我们只需要提取宏名称,然后忽略后面的所有内容。 步骤: 1. 读取每一行。 2. 使用空格分割,找到第二个单词(因为第一个是#define,但是原代码中每行都是以#define开头,所以第二个单词就是宏名称)。 注意:有些宏名称中可能包含下划线,比如RELAY_I2C_OVI,所以我们需要将整个宏名称提取出来。 3. 然后重新组合成:`#define 宏名称 "宏名称"` 但是,注意原代码中宏名称后面还有内容,我们不需要。 我们按行处理,忽略行尾的注释等。 另外,注意原代码中有一行: #define RELAY_VDD_CTG_4 40. 104, -1 这里40后面是一个点,可能是笔误,但我们在处理时,只需要宏名称,所以不受影响。 开始转换: 原行示例: #define RELAY_I2C_OVI 0, 64, -1 -> 转换后: #define RELAY_I2C_OVI "RELAY_I2C_OVI" 但是,注意:新格式中,字符串是双引号,而示例中写的是“RELAY_SS”(注意是中文引号?)但实际代码中应该是英文双引号。所以我们应该使用英文双引号。 因此,我们输出时使用英文双引号。 下面我们逐行转换: 原代码: #define RELAY_I2C_OVI 0, 64, -1 #define RELAY_CELL_SOUR 1, 65, -1 ...(以此类推) 转换后: #define RELAY_I2C_OVI "RELAY_I2C_OVI" #define RELAY_CELL_SOUR "RELAY_CELL_SOUR" ... 注意:原代码中有一行是: #define RELAY_VDD_CTG_4 40. 104, -1 我们同样处理,宏名称是RELAY_VDD_CTG_4,所以转换后: #define RELAY_VDD_CTG_4 "RELAY_VDD_CTG_4" 但是,注意原代码中这一行的数字部分有错误(40.后面是点),但我们在转换中不需要,所以忽略。 另外,注意原代码中有一行: #define RELAY_L_Exchange 5, 69, -1 宏名称是RELAY_L_Exchange,注意这里有一个大写字母E,转换后字符串中也要保留。 因此,我们只需要提取宏名称,然后原样输出。 编写转换代码(由于问题要求输出转换后的代码,我们直接处理每一行): 由于输入是文本,我们可以用字符串处理。 具体步骤: - 按行读取输入。 - 对于每一行,去掉行尾的换行符。 - 使用空格分割,但注意宏名称是第二个单词(因为第一个是#define),但是宏名称可能由多个部分组成(用下划线连接),所以我们需要从第二个单词开始,直到遇到第一个纯数字(或非下划线字母)为止?这样处理比较复杂。 另一种方法:我们只需要找到#define后面的第一个单词(即紧接着#define的第一个非空格字符串),然后忽略后面的所有内容。 所以,我们可以这样: - 使用字符串的split()方法,分割空格,那么第二个元素就是宏名称(因为第一个是"#define")。 - 注意:有些行可能有多个空格,但我们可以用split()默认的连续空格视为一个分隔符。 例如: line = "#define RELAY_I2C_OVI 0, 64, -1" parts = line.split() 则parts[0] = "#define", parts[1] = "RELAY_I2C_OVI", 后面的忽略。 因此,转换后的行就是: "#define " + parts[1] + &#39; "&#39; + parts[1] + &#39;"&#39; 但是,注意原代码中有一行: #define RELAY_VDD_CTG_4 40. 104, -1 分割后:parts[0] = "#define", parts[1]="RELAY_VDD_CTG_4", parts[2]="40."(注意这里有一个点),但我们不需要。 所以,我们按照这个规则处理每一行。 但是,注意原代码中有一个宏名称是RELAY_SS,但我们的输入中并没有RELAY_SS,所以转换后也不会出现RELAY_SS,而是原来的各个宏名称。 因此,我们输出转换后的每一行。 开始转换: 注意:原代码中最后一行是: #define RELAY_DAC_PULL 43, 107, -1 我们按上述规则转换。 输出转换后的代码。</think>以下是修改后的代码,已将每个 `#define` 宏转换为指定格式 `#define RELAY_SS "RELAY_SS"`,其中宏名称保持不变,值替换为自身名称的字符串形式: ```c #define RELAY_I2C_OVI "RELAY_I2C_OVI" #define RELAY_CELL_SOUR "RELAY_CELL_SOUR" #define RELAY_VDD_SOUR "RELAY_VDD_SOUR" #define RELAY_QVM_POUT "RELAY_QVM_POUT" #define RELAY_L_Exchange "RELAY_L_Exchange" #define RELAY_CTG "RELAY_CTG" #define RELAY_QVM_CELL "RELAY_QVM_CELL" #define RELAY_CELL_POUT "RELAY_CELL_POUT" #define RELAY_QSRT_TMU "RELAY_QSRT_TMU" #define RELAY_READY "RELAY_READY" #define RELAY_QSRT "RELAY_QSRT" #define RELAY_M24128 "RELAY_M24128" #define RELAY_OP177 "RELAY_OP177" #define RELAY_I2C_DIO "RELAY_I2C_DIO" #define RELAY_VDD_CELL "RELAY_VDD_CELL" #define RELAY_BUF_IN "RELAY_BUF_IN" #define RELAY_CELL_CAP "RELAY_CELL_CAP" #define RELAY_DAC_POUT "RELAY_DAC_POUT" #define RELAY_VDD_CTG_4 "RELAY_VDD_CTG_4" #define RELAY_DAC_DIO "RELAY_DAC_DIO" #define RELAY_QVM_NOUT "RELAY_QVM_NOUT" #define RELAY_DAC_PULL "RELAY_DAC_PULL" ``` **修改说明**: 1. 移除了原始宏定义中的数字参数(如 `0, 64, -1`)。 2. 将宏的值替换为**宏名称自身的字符串**(用双引号包裹)。 3. 保留了所有原始宏名称(如 `RELAY_I2C_OVI` 等)。 4. 修正了 `RELAY_VDD_CTG_4` 的笔误(原代码中的 `40.` 改为正确的宏名称)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值