企业官网建设流程全解析

• 前端
• UI组件

react-admin 并非只有一个仓库、一个 npm 包。绝大多数组件虽然来自核心仓库marmelab/react-admin，但围绕它已经形成了一个分层生态：官方开源的多包 Monorepo、基于订阅分发的 Enterprise Edition（EE）商业包，以及社区维护的第三方扩展包。本文以仓库根目录 docs/Ecosystem.md 为主体脉络，结合本仓库实际源码结构，完整梳理这一生态的组成、每个包的定位与仓库内对应的权威文档，帮助你在引入新能力时准确找到正确的包与文档入口。

生态总览：一个核心，三层扩展

原文档开宗明义：react-admin 的组件主体来自marmelab/react-admin主仓库，但还有更多 hooks 与组件分布在其他包中。从本仓库的实际结构看，这个生态可以划分为清晰的三层：

1. 官方开源核心层：packages/目录下的 18 个包，包括聚合包react-admin、核心逻辑包ra-core、UI 组件包ra-ui-materialui、数据提供器适配器（ra-data-*）、国际化包（ra-i18n-*、ra-language-*）等，全部随核心仓库以 MIT 协议发布；
2. Enterprise Edition 商业层：@react-admin/ra-*系列共 15 个订阅制包，托管在私有 npm registry 中，提供实时协作、RBAC、树形结构、日历等高级能力；
3. 社区第三方层：由独立开发者/公司维护的 9 个典型扩展包，覆盖 Google Maps 展示、CSV 导入、资源聚合视图等场景。

本文档所在的docs/目录本身就承担了"生态导航图"的职责：它既收录了每个官方开源包对应的使用文档（如 DataProviders.md、List.md），也收录了 EE 包对应的专册文档（如 Realtime.md、Tree.md、AuthRBAC.md），是检索整个生态能力的第一入口。

官方开源层：Monorepo 与 18 个 npm 包

Monorepo 组织方式

仓库采用 Lerna 管理的 Monorepo 结构。根目录 lerna.json 记录了"version": "5.15.3"（与当前仓库各包版本一致），并由根目录 package.json 中的workspaces声明将packages/*、examples/*、cypress、docs_headless统一纳入 Yarn workspace 管理。根package.json中的test-unit、test-e2e、build、run-demo、run-crm等脚本即为整个生态的构建与验证入口。

react-admin聚合包：生态的"总出口"

对应用开发者而言，日常只面向一个入口包react-admin。从 packages/react-admin/package.json 的依赖声明可以清楚看到它的聚合作用：

• 将ra-core（数据获取、认证、i18n、状态管理等核心逻辑）与ra-ui-materialui（基于 Material UI 的组件实现）组合为统一 API；
• 预置ra-i18n-polyglot与ra-language-english提供开箱即用的默认翻译；
• 直接依赖@tanstack/react-query（数据请求）、react-hook-form（表单）、react-router（路由），即以官方推荐的三大底层库作为运行时依赖；
• 以react、react-dom作为peerDependencies（要求 React 18 或 19）。

也就是说，应用层npm install react-admin之后拿到的，就是这个生态中开源核心层的完整聚合产物。

官方开源包清单

按职能划分，packages/目录下的开源包包括：

官方文档宣称数据提供器适配器总数超过 50 种，适配 REST、GraphQL 等多种 API 风格，完整清单见 DataProviderList.md；编写自有适配器的方法见 DataProviders.md。这套"适配器 + 数据提供器抽象"的设计正是生态能够横向扩展的根基——实时、缓存等高级能力都建立在同一抽象之上。

Enterprise Edition：15 个订阅制商业包

原文档用专门章节列出 Enterprise Edition（EE）的 15 个包。EE 包托管于私有 npm registry，需订阅 EE 计划获取访问权限；它们以@react-admin/ra-*命名，聚焦核心框架之外的"重活"：实时协作、细粒度权限、树、日历、AI 增强等。以下完整罗列这 15 个包，并给出本仓库docs/目录中对应可深入阅读的文档入口：

引入方式：以ra-editable-datagrid为例

EE 包的引入方式与普通 npm 包一致，区别在于 npm registry 需要切换为 EE 私有源。以 EditableDatagrid.md 的安装示例为准：

npm install --save @react-admin/ra-editable-datagrid # 或 yarn add @react-admin/ra-editable-datagrid

原文档特别提示：ra-editable-datagrid等 EE 包托管在私有 npm registry，需订阅 EE 任一计划后才能访问该源。安装后即可在<List>、<ReferenceManyField>等提供ListContext的组件中用<EditableDatagrid>替换<Datagrid>，并传入createForm/editForm实现在列表内直接增删改记录。

深度示例：ra-realtime的能力如何落地

为说明 EE 包并非"黑盒"，可以以生态中典型的ra-realtime为例，看 Realtime.md 描述的实际工作方式：

• 后端无关：与 CRUD 一样采用适配器思路，复用dataProvider收发事件，因此可对接 Mercure、API Platform、Supabase、Socket.IO、Ably 等多种实时基础设施，数据提供器需满足 RealtimeDataProvider.md 中列出的方法要求；
• 发布/订阅机制：发布侧调用usePublish()向主题发送事件，订阅侧用useSubscribe(topic, callback)接收：

// 发布侧 const [publish] = usePublish(); publish(topic, event); // 订阅侧 useSubscribe(topic, callback);

• 上层封装：基于此提供usePublish、useSubscribe、useSubscribeCallback、useSubscribeToRecord、useSubscribeToRecordList等高级 hooks，并派生出<ListLiveUpdate>、<ShowLiveUpdate>、<EditLiveUpdate>等组件——在<List>中加入一行<ListLiveUpdate />即可让列表在数据新增/更新/删除时自动刷新。

这展示了生态的一条通用规律：EE 包的能力通常建立在核心层的 hooks、数据提供器与 Store 等抽象之上，且每个包在docs/中都有可对照源码细读的专册。

社区第三方包

原文档还列出了 9 个社区维护的第三方包，它们覆盖核心框架未内置的场景，可作为选型参考：

• FusionWorks/react-admin-google-maps：用于展示位置的 Google Maps 输入/视图组件；
• api-platform/admin：为支持 Hydra Core Vocabulary 的 API（包括但不限于 API Platform 框架创建的 API）生成功能完整的 React Admin 应用；
• zifnab87/ra-component-factory：集中配置字段/菜单链接/操作按钮的不可变性与可见性，按权限角色便捷重排字段/属性与重组标签页；
• ctbucha/bs-react-admin：React Admin 的 BuckleScript 绑定；
• dryhten/ra-resource-aggregator：资源聚合器，允许在同一个视图中编辑/创建/删除多个资源；
• react-admin-import-csv（benwinding）：为 react-admin 提供 CSV 文件导入按钮；
• @bb-tech/ra-components（BigBasket）：层级菜单结构、JSON 字段与输入、Email/URL/Phone 输入组件；
• Vycanis Modeler：从 ER 图（ERD）快速生成 React Admin 应用；
• Dev XP 演示视频：介绍如何在本地修改 react-admin 核心项目。

这些包由各社区作者独立维护，功能与维护活跃度请以其仓库为准；本文仅转述原文档收录时的定位描述。

扩展生态的协作入口

原文档在结尾说明了生态清单的演进方式：如果你编写或了解到其他 react-admin 扩展包，可以在docs文件夹上提交 Pull Request，将包加入本清单。这意味着 docs/Ecosystem.md 本身就是一个由社区共同维护的"生态登记处"，新包通过合入此清单获得官方文档站的收录与曝光。

选型建议：如何在生态中找到正确的包

综合全文，在实际项目中定位生态能力时可遵循以下次序：

1. 先查核心层：通用 CRUD、数据获取、表单、认证、i18n 等绝大多数需求，直接使用react-admin聚合包即可，无需额外依赖；
2. 再查 EE 层：当需求升级为实时协作、RBAC、树/日历/搜索等高级场景，先在docs/中检索对应 EE 专册（上表已给出完整映射），确认能力边界后再订阅 EE 并引入对应@react-admin/ra-*包；
3. 最后查社区层：核心与 EE 都未覆盖的长尾需求（如地图、CSV 导入），可评估第三方包，但需自行核实维护状态与兼容性。

整个生态的开放接口（数据提供器、i18n 适配器、Store、hooks 体系）都定义在 ra-core 与 ra-ui-materialui 两个开源包中，阅读其源码是理解所有扩展包工作原理的最高效路径。

• 前端
• UI组件