Commit a4fa4a39 authored by David Yang's avatar David Yang

docs: standardize on HeroUI components

parent f69d2c27
......@@ -19,14 +19,16 @@
- **组件函数**:必须使用大驼峰形式,例如 `const UserHeader = () => { ... }`。
- **变量与普通函数**:使用小驼峰 (camelCase)。
- **常量**:使用全大写下划线 (SNAKE_CASE)。
- **技术栈偏好**:
- **技术栈要求**:
- 优先使用 React Hooks 和函数组件。
- 样式处理:**优先使用 Hero UI / HeroUI Pro(`@heroui/react`、`@heroui-pro/react`)+ Tailwind CSS**。
- 交互组件:**优先使用 Hero UI 组件**;只有在 Hero UI 缺少对应能力且项目已有封装无法满足时,才考虑直接使用底层无样式交互库或自定义实现。
- 样式处理:**全项目统一使用 Hero UI / HeroUI Pro(`@heroui/react`、`@heroui-pro/react`)+ Tailwind CSS**。
- 交互组件:**必须优先使用 Hero UI / HeroUI Pro 组件**;只有在 Hero UI 缺少对应能力且项目已有 Hero UI 封装无法满足时,才可基于 Hero UI 设计规范和现有样式变量自定义实现。
- 组件选择优先级(从高到低):
1. `@heroui/react` / `@heroui-pro/react` 中的组件(Button/Input/Modal/Table/Autocomplete/Select/Checkbox/Textarea/Dropdown/DatePicker/...)
2. 基于 Hero UI 设计规范和项目现有样式变量的自定义组件(仅在 Hero UI 无现成组件时)
3. 原生 HTML + 自写样式(尽量避免)
- **禁止使用 `catalyst-ui-kit` 及其组件**,不得新增、恢复或复制 Catalyst 组件、样式、依赖和兼容封装。
- 修改仍使用 Catalyst 的存量页面或组件时,必须在本次改动中迁移为 Hero UI / HeroUI Pro,不得继续沿用 Catalyst 实现。
## 4. 接口请求规范
......@@ -41,9 +43,11 @@
## 6. UI 规范(Hero UI 强制约束)
- **全项目 UI 统一**:默认使用 Hero UI / HeroUI Pro 组件与样式体系,避免引入其它 UI 框架或继续新增 Catalyst 组件依赖。
- **Hero UI 优先**:弹窗、下拉、选择器、表格、表单、导航等交互优先使用 `@heroui/react` 或 `@heroui-pro/react`。
- **一致性**:表单控件优先用 Hero UI 的 `Input`、`Select`、`Checkbox`、`Textarea`、`Autocomplete`、`DatePicker` 等,表格用 `Table`,对话框用 `Modal` / `Drawer`。
- **唯一 UI 体系**:全项目必须统一使用 Hero UI / HeroUI Pro 组件与样式体系,不得引入或使用其它 UI 组件库替代 Hero UI。
- **Catalyst 禁用**:`catalyst-ui-kit` 已停止使用;禁止从该组件库导入组件,禁止新增其依赖、样式、适配层或兼容封装。
- **Hero UI 强制优先**:弹窗、抽屉、下拉、选择器、表格、表单、导航等交互必须优先使用 `@heroui/react` 或 `@heroui-pro/react`。
- **一致性**:表单控件使用 Hero UI 的 `Input`、`Select`、`Checkbox`、`Textarea`、`Autocomplete`、`DatePicker` 等,表格使用 `Table` / HeroUI Pro `DataGrid`,对话框使用 `Modal` / `Drawer`。
- **存量迁移**:发现仍使用 Catalyst 的代码时,应迁移到语义对应的 Hero UI / HeroUI Pro 组件,并保持原有业务行为、数据协议和可访问性不变。
- **可访问性**:移动端侧栏、弹层、下拉和选择器必须使用 Hero UI 提供的可访问性能力(focus 管理、esc 关闭、键盘导航等)。
# AI 开发执行规范
......
# UI Architecture
Updated: 2026-08-19
Updated: 2026-08-25
## Framework Boundary
Production pages and shared UI compositions import HeroUI/HeroUI Pro directly.
The application must not keep Catalyst, Headless UI or native visible controls
as a compatibility boundary.
HeroUI and HeroUI Pro are the project's only UI component system. Production
pages and shared UI compositions import `@heroui/react` or
`@heroui-pro/react` directly. New UI work must not introduce another component
library as an alternative implementation.
`catalyst-ui-kit` is retired. Production and shared code must not import, copy,
restore or wrap Catalyst components, styles or dependencies. When a touched
area still contains Catalyst code, that code must be migrated to the equivalent
HeroUI or HeroUI Pro component while preserving its business behavior and
accessibility contract.
Allowed shared components are business-neutral HeroUI-native compositions such
as a material DataGrid shell, configuration Autocomplete, date field, file
......@@ -51,12 +58,13 @@ The removed portable/app-token layers must not be reintroduced.
- Shared UI owns layout, accessibility and HeroUI composition only.
- Routes keep the Umi base `/audit_material_manager/` and existing auth wrappers.
## Removal Order
## Legacy UI Policy
1. Replace application switcher Headless root with HeroUI Modal.
2. Replace material archive Catalyst controls at their call sites.
3. Replace selection/table/upload surfaces with Pro DataGrid, ActionBar,
EmptyState and DropZone.
4. Remove unreachable Catalyst imports and package dependencies.
5. Delete the historical kit only after production references reach zero.
6. Keep API empty/error states truthful; do not introduce demo records as a UI fallback.
1. Do not add or restore Catalyst imports, components, styles, dependencies,
compatibility wrappers or copied implementations.
2. Replace any Catalyst code encountered in a touched area with the semantic
HeroUI or HeroUI Pro equivalent.
3. Use HeroUI Pro DataGrid, ActionBar, EmptyState and DropZone for their
corresponding advanced interaction patterns.
4. Preserve existing business behavior, loading/error/empty states and API
contracts during migration; do not introduce demo records as a UI fallback.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment