GraphQL 与 Relay:数据驱动 React 应用中的查询语言与客户端数据管理
前端开发工具【免费下载链接】relayRelay is a JavaScript framework for building>项目地址https://gitcode.com/gh_mirrors/relay29/relay点击查看免费下载导读本篇是 Relay 官方教程v17 版中「GraphQL and Relay」一节的深度讲解面向刚接触 Relay 的 React 开发者。文章先厘清 GraphQL 作为一种查询语言与 REST 接口的本质差异再通过新闻流newsfeed示例 Schema 说明节点、边、类型系统等核心概念最后拆解 Relay 在其中的独特定位用编译器把组件局部的数据声明Fragment拼装成整屏查询并用归一化的 Store 保证跨组件数据一致。读完你将掌握 GraphQL 查询 / 变更 / 订阅的基本语义理解 Relay 编译器与运行时各自承担的职责并能在后续教程中带着清晰的心智模型开始编写代码。一、GraphQL按需查询的服务器数据语言GraphQL 是一种用于在服务器上查询和修改数据的语言。它与传统 HTTP API 最本质的区别在于传统接口暴露的是固定的端点集合而 GraphQL 服务器提供的是一整套可选数据的面板palette客户端可以从这个面板中任意组合自己需要的数据。这种设计给前端开发带来的直接收益是无需为数据需求变化而反复编写、部署新端点。字段变了改查询即可新版本客户端只需请求自己需要的数据不会因为兼容旧版本而携带多余字段。同时GraphQL 为跨任意后端查询数据提供了统一接口。无论数据源是关系型 SQL 数据库、图数据库还是由大量微服务组成GraphQL 服务器都能从多个后端汇总数据在一次响应中返回给客户端这比客户端逐个服务发请求要高效得多。1.1 与传统 REST 的直观对比传统 HTTP API 中每个 URL 返回固定的一组信息Request: GET /person?id24601 Response: {id: 24601, name: Jean Valjean, age: 64, occupation: Mayor}而在 GraphQL 中客户端精确指定自己想要的信息服务器只返回被请求的信息Request: query { person(id: 24601) { name occupation } } Response: { person: { name: Jean Valjean, occupation: Mayor } }注意响应中只包含客户端明确请求的字段——age没有被请求也就没有返回。二、图模型节点Nodes与边Edges正如其名GraphQL 将数据组织成一张图graph。图由两类元素构成节点nodes类似于对象或记录例如一个Person边edges从一个节点指向另一个节点的指针例如Person - Location。2.1 沿边遍历一次查询取回多层级数据GraphQL 允许你沿着边从一个节点走到另一个节点并请求途经每个节点的信息。例如从一个人走到他的城市再取回城市的信息query { person(id: 24601) { name occupation location { name population } } }{ person: { name: Jean Valjean, occupation: Mayor, location: { name: Montreuil-sur-Mer, population: 1935 } } }这意味着你可以在一次查询中取回一整屏对象的数据——不必像 REST 那样为每个 UI 界面分别编写并维护独立端点也不用在客户端串行发出多个请求。三、Schema描述图的语言服务器提供的可选数据由Schema模式定义。Schema 描述了图中存在哪些种类的节点类型节点之间如何连接边每个节点包含哪些信息字段。客户端在 Schema 之上挑选所需信息。本教程的示例应用是一个新闻流应用它的 Schema 中包含如下类型Story一条新闻流动态字段包括标题、图片以及指向发布者的边Person姓名、邮箱以及指向其他Person的朋友列表即边Viewer当前浏览应用的人包含其新闻流动态列表等信息Image图片本身的 URL 以及alt文字描述。下面的 Schema 片段来自示例应用的定义先建立整体印象即可// 一条新闻流动态。它既有标量字段如字符串和数字 // 也有指向图中其他节点的边例如 thumbnail 和 poster type Story { id: ID! category: Category title: String summary: String thumbnail: Image poster: Actor } // Actor 是可以在站点上执行操作的实体。 // 这是一个接口可以由多个不同类型实现此处为 Person 和 Organization interface Actor { id: ID! name: String profilePicture: Image } // 实现该接口的具体类型 type Person implements Actor { id: ID! name: String email: String profilePicture: Image location: Location } // Schema 还可以定义枚举例如新闻流动态的类别 enum Category { EDUCATION NEWS COOKING }3.1 从仓库源码看真实 Schema 形态教程中的这段 Schema 是对概念的精简示意。在当前仓库中可以看到一个完整的、真实可用的 Schemapackages/relay-test-utils-internal/testschema.graphql。它同样以「Query / Mutation / Subscription」三个根操作类型开篇并完整呈现了上述概念在真实项目中的样子根查询类型通过viewer: Viewer、story: Story、node(id: ID): Node等字段作为整张图的入口见 testschema.graphqlinterface Actor定义了id、name、profilePicture、friends等字段而Page、User等类型通过implements声明自己属于该接口见 testschema.graphqltype Story implements FeedUnit Node MaybeNodeInterface展示了多接口实现的写法其中attachments、actor、comments等字段即指向图中其他节点的边见 testschema.graphqltype Viewer拥有newsFeed(after: ID, first: Int, find: ID): NewsFeedConnection这样的连接字段——这正是教程后续「Connections 与分页」章节的基础见 testschema.graphql。可以看出教程示例与仓库中的测试 Schema 一脉相承对象类型、接口、枚举、连接字段都是 Schema 语言表达节点 边 节点信息的标准化手段。四、查询、变更与订阅图上的三类操作除了查询QueryGraphQL 还支持变更Mutation请求服务器更新数据。如果查询类比 HTTP 的 GET那么变更就相当于 POST——它同样允许服务器返回更新后的数据订阅Subscription维持一条打开的连接用于实时更新。GraphQL 通常基于 HTTP 实现因此查询与变更不仅是 GET / POST 的类比实际上也可以就以 GET / POST 的方式发送见 testschema.graphql 中schema { query / mutation / subscription }的三个根类型声明。五、Relay面向 GraphQL 的客户端数据管理库讲完 GraphQL再来看 Relay 的角色。Relay 是一个面向客户端的、围绕 GraphQL 构建的数据管理库但它以一种非常特定的方式使用 GraphQL从而把它的收益最大化。5.1 它要解决的根本矛盾从性能角度出发你希望每个屏幕 / 页面在开始时只发一次请求而不是让每个组件各自发请求。但这样做会带来严重的维护问题如果某个组件需要新增数据你必须找到使用该组件的每一个屏幕手动把新字段加进每个屏幕的查询里如果某个字段不再需要你又要从每个查询里删除它——但这时你无法确定该字段是否还被其他组件使用。这种整屏大查询极难维护。5.2 Relay 的独特解法本地声明 编译拼装Relay 的核心优势在于规避了这一取舍每个组件在自己的代码中声明数据需求Fragment再由编译器把这些局部需求拼装成更大的完整查询。这样性能和可维护性可以兼得。编译器扫描 JavaScript / TypeScript 代码中的 GraphQL 片段Fragment再把它们拼接成完整查询。这一点可以从仓库的编译器实现中得到印证compiler/crates/relay-compiler是整个编译器的核心 crate其 54 个源码文件覆盖了从 GraphQL 语法解析compiler/crates/graphql-syntax、依赖分析compiler/crates/dependency-analyzer到最终代码生成compiler/crates/relay-codegen的完整流水线并有上千条测试用例compiler/crates/relay-compiler/tests下 328 个.graphql输入与 538 个.expected快照验证 Fragment 拼接与类型生成的正确性。5.3 运行时Store、归一化与一致性除编译器外Relay 还有负责获取和处理 GraphQL 数据的运行时。它维护一个本地缓存缓存所有已取回的数据这个缓存被称为Store然后按每个组件的 Fragment 把属于它的数据分发出去集中式 Store 的核心价值在于数据更新时的一致性。例如 UI 提供修改姓名的入口你只需在一处执行更新所有展示该姓名的组件都会看到新信息——即使它们位于不同屏幕、当初通过不同查询取得数据。原因在于 Relay 会对进入的数据做归一化normalize把同一个图节点node的所有数据合并到一处避免同一个节点在缓存中出现多份拷贝。仓库中packages/relay-runtime/store/目录下的RelayResponseNormalizer.js、RelayModernStore.js正是这一机制的实现所在。更进一步Relay 提供的不仅是查询它覆盖了查询与更新的完整生命周期包括乐观更新optimistic updates与回滚分页paginate数据刷新refresh。当 Store 中的数据更新时Relay 会高效地只重渲染正在展示该数据的那些组件。六、小结GraphQL是一种把数据建模为图、并从服务器查询以及更新该数据的语言客户端按需指定字段一次请求即可沿边取回整屏数据Relay是一个基于 React 的 GraphQL 客户端库它允许每个组件通过与其**同置co-located**的 Fragment 局部声明数据需求再由编译器拼装成完整查询数据取回后Relay 通过归一化的 Store维持数据一致性并在数据更新时精准重渲染相关组件。带着这张图模型 客户端编译拼装 Store 归一化的认知地图就可以进入教程的下一节开始动手编写第一个 Relay 查询了。赞分享前端开发工具【免费下载链接】relayRelay is a JavaScript framework for building>项目地址https://gitcode.com/gh_mirrors/relay29/relay点击查看免费下载相关推荐Vencord GraphQL集成与数据查询现代化Discord客户端的数据管理革命Vencord GraphQL集成与数据查询现代化Discord客户端的数据管理革命 还在为Discord客户端的数据获取和状态管理头疼吗传统REST AP即时通讯桌面应用前端插件系统Relay 查询入门用 graphql 标签、useLazyLoadQuery 与编译器生成类型构建数据驱动的 React 应用Relay 查询入门用 graphql 标签、 useLazyLoadQuery 与编译器生成类型构建数据驱动的 React 应用 本篇技术指南围绕 Rela前端开发工具抖音批量下载完整指南无水印视频、背景音乐与合集一次收齐抖音批量下载完整指南无水印视频、背景音乐与合集一次收齐 想把某位创作者主页的作品一次收齐却只能一条条手动点保存douyin downloader 是一个免网页爬虫CLI创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考