前端开发工具【免费下载链接】relayRelay is a JavaScript framework for building>项目地址https://gitcode.com/gh_mirrors/relay29/relay点击查看免费下载Relay 在 React 17 上发布的 Relay Hooks 全面采用了 React Suspense 来管理加载状态但官方明确表示 Suspense for Data Fetching 尚未达到通用落地标准。本文以 suspense-compatibility.md 为骨架结合 loading states、refetching、relay-resolvers 等官方文档与react-relay运行时源码系统讲解 Relay 对 Suspense 的立场、在 React 17 下使用 Relay Hooks 的实际行为与已知局限以及如何用 Suspense 边界Suspense Boundary与fetchQuery兜底方案编写可运行的加载状态代码。为什么是 SuspenseRelay Hooks 的加载状态机制在 Relay 17 的文档中Loading States with Suspense 明确指出usePreloadedQuery与useLazyLoadQuery在数据仍在网络层获取时会暂停suspend渲染。这是组件表达异步依赖数据、代码、图片的一种方式——组件挂起时React 会渲染上层Suspense组件提供的fallback直到子树中所有挂起组件就绪。这也是用户看到Relay Hooks 使用 Suspense 指定加载状态这一事实的来源guided-tour/rendering/loading-states.md 中的原话。于是一个自然的疑问产生了既然 Suspense for Data Fetching 仍然没有得到 React 官方支持Relay 为什么还要在 React 17 上依赖它这是否意味着 React 17 已经官方支持 Suspense for Data Fetching 了这正是本文主题文档 suspense-compatibility.md 要回答的问题。Suspense for Data Fetching 就绪了吗答案是否定的原文档给出的结论非常明确支持Support、通用指导general guidance以及使用 Suspense for Data Fetching 的要求requirements仍未就绪React 团队仍在为即将到来的 React 版本定义这一指导方案。也就是说Relay 在 React 17 上使用 Suspense不代表 Suspense for Data Fetching 已经可以被广泛实现与采用。二者是两回事Suspense 作为 React 的渲染协调机制已经可用Relay 用它来表达数据尚未就绪但如何在任意场景下用 Suspense 做数据获取的完整规范、边界条件与最佳实践React 团队仍在制定中。同样的警告也出现在 loading-states.md 的 caution 区块里它明确提醒读者这并不意味着 Suspense for Data Fetching 已准备好通用落地并链接回本文主题文档。既然未就绪为什么 Relay 仍选择在 React 17 发布 Relay Hooks原文档给出了两条核心理由这也是理解 Relay 产品节奏的关键。理由一Relay 是 Suspense 的早期采用者与共同研究者Relay 是最早采用 Suspense 的项目之一并与 React 团队在 Suspense for Data Fetching 的研究上进行了协作是 Suspense 在生产环境中的首批试验田之一帮助影响了其设计决策。正因如此Relay 的 Suspense实现中仍保留着早期学习阶段的痕迹这些早期经验尚未被完整文档化实现尚未完全达到 Relay 团队满意的状态在 React 17 上使用 Suspense 会存在一些限制。但 Relay 团队认为 Relay Hooks 处于正确的演进轨迹上这些实现层面的后续调整可以被平滑吸收因此选择提前发布。理由二Relay Hooks API 本身是长期稳定的即使底层实现仍在演进未来随着 React 团队完善 Suspense for Data Fetching 指导实现还会继续变化Relay Hooks 的 API 面是稳定的已在 Facebook 内部被广泛采用已在生产环境运行超过一年团队对 API 的可用性有信心希望通过发布让社区尽早采用并获得外部反馈。从源码看这一API 稳定、实现演进的定位与react-relay中的注释相互印证——例如 useLazyLoadQuery.js 中明确指出useLazyLoadQuery存在若不加谨慎使用可能触发嵌套/瀑布式往返请求的性能风险并建议优先使用usePreloadedQuery说明 API 层面对使用模式的引导是长期、稳定的设计决策而非临时实现。在 React 17 采用 Relay Hooks 意味着什么原文档对采用者给出了两点明确告知。局限一React 17 下存在功能子集限制当前发布包含一个同时兼容同步渲染与并发渲染的功能子集。要完整支持 Suspense for Data Fetching还需要如下能力并发渲染挂起中的组件树concurrently rendering suspended trees数据 refetch 时向新组件树过渡transitioning to new trees when data is refetched。当前已发布的 API 将允许 Relay 在未来的 React 版本中以相同的 API 支持并发渲染。也就是说限制在于 React 17 的运行时能力而不是 Relay API 本身。局限二未来会与 React 并发大版本同步发布当 React 推出完整支持并发渲染与 Suspense for Data Fetching 的版本时Relay 会同步发布一个新的 major 版本。该版本很可能包含破坏性变更breaking changesRelay 会为升级过程提供文档。这一预期在文档中有多处呼应。例如 OssAvoidSuspenseNote.md 指出在未来支持并发渲染的 React 版本中React 将提供选项避免在挂起时用 Suspense fallback 隐藏已渲染内容——这正是上述向新组件树过渡能力的一部分。在 React 17 下如何正确使用 SuspenseSuspense 边界与 fallback理解了立场之后关键问题变成在 React 17 上Relay 开发者究竟应该怎么写加载状态官方指南 loading-states.md 给出了完整方案。基本形态用Suspense包裹可挂起组件const React require(React); const {Suspense} require(React); function App() { return ( // Render a fallback using Suspense as a wrapper Suspense fallback{LoadingGlimmer /} CanSuspend / /Suspense ); }规则Suspense可以包裹任意组件当目标组件挂起时Suspense会渲染fallback直到子树中所有挂起组件都就绪即子树内所有挂起的组件全部 resolve。fallback 通常用于渲染 glimmer、占位符等加载 UI。聚合加载状态一个边界等待整棵子树function App() { return ( // A LoadingGlimmer for all content is rendered via the Suspense fallback Suspense fallback{LoadingGlimmer /} MainContent / SecondaryContent / {/* SecondaryContent can also suspend */} /Suspense ); }MainContent与SecondaryContent都可以挂起原因不限于取数也可能是代码、图片等异步资源用一个Suspense包裹它们可以直到全部就绪后再一次性绘制整块内容避免加载元素如 spinner的意外闪烁——这正是 Suspense 相比手动 loading 状态的关键优势之一。粒度控制多个边界允许内容尽早呈现function App() { return ( {/* Show a separate loading UI for the LeftHandColumn */} Suspense fallback{LeftColumnPlaceholder /} LeftColumn / /Suspense {/* Show a separate loading UI for both the Main and Secondary content */} Suspense fallback{LoadingGlimmer /} MainContent / SecondaryContent / /Suspense / ); }更细粒度地包裹组件可以让已经就绪的组件更早渲染上例中LeftColumn一旦就绪即可先绘制不必等待右侧两个内容区。这是 React 17 同步渲染模式下 Suspense 最重要的实用技巧。在 Relay 查询中的实际形态查询渲染组件Query Component本身是可挂起组件function MainContent(props) { // Fetch and render a query const data usePreloadedQuery( graphql..., props.queryRef, ); return (...); }function App() { return ( Suspense fallback{LoadingGlimmer /} MainContent / {/* MainContent may suspend */} /Suspense ); }流程拆解MainContent尝试取数时会挂起渲染表示还没准备好包裹它的Suspense检测到挂起渲染 fallbackLoadingGlimmer查询取回后MainContentresolveReact 重新尝试渲染。除查询外Fragment也与 Suspense 集成用于渲染defer的数据或 Relay Store 中部分可用的数据partial rendering见 rendering-partially-cached-datarefetch/refreshing 与 connection 渲染 API同样会在这些场景下挂起见 refetching 与 connections。过渡与更新中的挂起React 17 的已知缺口loading-states.md 的 Transitions and Updates that Suspend 一节进一步明确了 React 17 的限制场景应用在已挂载边界内切换组件时例如从内容 A 切换到内容 B新组件可能尚未加载完异步依赖同样会挂起此时仍会显示Suspense边界 fallback——意味着用 fallback 隐藏已有内容在未来支持并发渲染的 React 版本中React 将提供选项来避免这一行为即挂起时不隐藏已渲染内容。这与主题文档提到的并发渲染挂起中的组件树、refetch 时过渡到新树是同一能力缺口的两面。需要避免 Suspense 时fetchQuerystore-only兜底方案对于不希望用 Suspense fallback 隐藏已渲染内容的场景例如 refetch 时希望保留旧内容官方在 refetching-queries-with-different-data.md 中提供了明确的替代方案用fetchQuery手动取数 自行维护 loading 状态。以useQueryLoader/loadQuery为例const environment useRelayEnvironment(); const [queryRef, loadQuery] useQueryLoader(AppQuery, props.appQueryRef); const [isRefetching, setIsRefetching] useState(false); const refetch useCallback(() { if (isRefetching) { return; } setIsRefetching(true); // fetchQuery will fetch the query and write // the data to the Relay store. This will ensure // that when we re-render, the data is already // cached and we dont suspend fetchQuery(environment, AppQuery, variables) .subscribe({ complete: () { setIsRefetching(false); // *After* the query has been fetched, we call // loadQuery again to re-render with a new queryRef. // At this point the data for the query should // be cached, so we use the store-only // fetchPolicy to avoid suspending. loadQuery({id: different-id}, {fetchPolicy: store-only}); }, error: () { setIsRefetching(false); } }); }, [/* ... */]);关键要点自行维护isRefetching状态用它渲染 busy spinner而不隐藏MainContent先fetchQuery把数据写入本地 Relay Store完成后调用loadQuery更新queryRef并传入fetchPolicy: store-only——此时数据已在缓存中直接读缓存即可避免挂起。useLazyLoadQuery的对应方案同理用fetchQuery取数后更新 state 中的fetchKey与fetchPolicy: store-only触发重渲染完整示例见 refetching-queries-with-different-data.md。提示fetchPolicy的默认值为store-or-network。四种取数策略store-or-network/store-and-network/network-only/store-only的完整语义可在 useLazyLoadQuery.js 的Options类型注释与 Fetch Policies 指南中查阅。源码视角Relay 的 Suspense 底层实现理解了使用方式后可以从react-relay运行时源码确认其实现事实。缓存条目挂起状态QueryResource/SuspenseResourceQueryResource.js 是查询挂起行为的核心。其缓存条目类型定义了getValue(): Error | Promisevoid | QueryResult, setValue(Error | Promisevoid | QueryResult): void,getValue()可能返回三种值错误、尚未完成的 Promise、或查询结果。当值为 Promise 时组件处于挂起状态这与 Suspense 的 throw a Promise 约定一致——React 捕获到 Promise 后等待其 resolve再重新渲染组件。同时QueryResource内部维护了temporaryRetain/permanentRetain等数据保留机制并默认采用store-or-network取数策略对 live query 默认store-and-network。挂起的实现细节由 SuspenseResource.js 承担它封装了 Suspense 资源在挂起→resolve生命周期中的状态管理。这些模块在useLazyLoadQueryNode、useFragmentNode等 hooks 底层被调用统一驱动查询与 fragment 的挂起行为。usePreloadedQuery的挂起约定use-preloaded-query.md 给出了官方约定在 render 中消费 queryRef 时若查询仍 pendingusePreloadedQuery()调用会挂起suspend若查询失败则抛错throw an error否则返回查询结果。这解释了为什么文档总是要求为查询渲染组件提供Suspense边界加载中与 Error Boundary失败——挂起与抛错都是 Suspense 机制的一体两面。Relay Resolvers 的 Suspense 哨兵在 Relay Resolvers 的 Live Resolver 场景中Suspense 还有另一种形态suspense sentinel挂起哨兵。见 guides/relay-resolvers/suspense.mdimport {suspenseSentinel} from relay-runtime; /** * RelayResolver Query.myIp: String * live */ export function myIp(): LiveStatestring { return { read: () { const state store.getState(); const ipLoadObject state.ip; if (ipLoadObject.status LOADING) { return suspenseSentinel(); } return state.ip; }, subscribe: (cb) { return store.subscribe(cb); }, }; }规则若 Live Resolver 返回 suspense sentinel该字段的所有消费者都会挂起直到字段更新为非 sentinel 值即使某查询/片段是通过其他 resolver 的rootFragment间接读取到挂起字段也会挂起。这展示了 Suspense 机制在 Relay 中不仅服务于网络取数也被复用于实时数据尚未同步可用的加载状态表达。结语理性看待 Relay 17 的 Suspense综合官方文档与源码可以对 Relay 17 的 Suspense 立场做如下总结Relay Hooks 使用 Suspense 是既定设计用于加载状态、defer数据、partial rendering、refetch 与 connection 渲染等场景Suspense for Data Fetching 本身尚未就绪——React 团队仍在制定通用指导Relay 的早期实现痕迹也尚未完全文档化在 React 17 使用 Relay Hooks 是受支持但有边界的选择当前是兼容同步渲染与并发渲染的功能子集需要开发者用Suspense边界管理 fallback或在不想隐藏内容时改用fetchQuerystore-only的自管状态方案未来会随 React 并发版本同步升级届时 Relay 将发布包含破坏性变更的新 major 版本并同步提供升级文档——这正是 Relay 作为 React 数据层与 React 生态同频演进的体现。对于准备在 React 17 上采用 Relay Hooks 的团队建议优先阅读本文引用的 loading-states.md、refetching-queries-with-different-data.md 与 rendering/queries.md并结合 QueryResource.js 与 useLazyLoadQuery.js 理解底层行为从而在设计加载体验时做出符合当前版本能力边界的决策。赞分享前端开发工具【免费下载链接】relayRelay is a JavaScript framework for building>项目地址https://gitcode.com/gh_mirrors/relay29/relay点击查看免费下载相关推荐Relay Suspense 兼容性指南Suspense for Data Fetching 尚未就绪为何 Relay Hooks 仍可在 React 17 落地Relay Suspense 兼容性指南Suspense for Data Fetching 尚未就绪为何 Relay Hooks 仍可在 React 17前端开发工具Relay Suspense 兼容性指南为什么 Relay Hooks 在 React 17 上使用 SuspenseRelay Suspense 兼容性指南为什么 Relay Hooks 在 React 17 上使用 Suspense Relay Hooks 是 Relay前端开发工具Relay Suspense 兼容性指南理解 Relay Hooks 在 React 17 中的 Suspense 使用与限制Relay Suspense 兼容性指南理解 Relay Hooks 在 React 17 中的 Suspense 使用与限制 Relay Hooks us前端开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考