IssueReporter

何时用

把用户口头的「缺组件 / 出 bug / 想优化」收成一份字段齐全、可直接贴进 GitHub 的 issue 草稿——组件库自身的反馈入口、内部平台的「报障」按钮、文档站的「这页写错了」。

不要拿它当通用表单：字段清单由 issue 模板决定，不是任意 schema，通用录入用 ProForm；要弹层里做增删改查用 ModalForm；只想要一个 Markdown 输入框用 MarkdownEditor。

导入

Props

IssueReporterProps。IssueReporterModalProps 继承它，另加下表末尾的弹层专属项。

Events

Slots

无障碍

• 每个字段都包在 Field 里，label 经 Base UI 自动 htmlFor/id 关联，错误文案自动串 aria-describedby，无效态自动置 aria-invalid。
• 必填错误只在尝试提交后才展示（aria-invalid 同步），初次进入不会满屏红字。
• 超长降级用 Alert 说明原因，而不是把按钮置灰不给理由。
• 「复制 Markdown」按钮复制成功后按钮文字切换为「已复制」，1.5 秒后复原——文字变化对读屏可感知，不是只换图标。
• 类型下拉、相关组件下拉的键盘操作分别由 Select / Combobox 保证。

禁忌 / 坑

• 它不会替你创建 issue，也不该拿到 token。 组件只做两件事：onSubmit(draft) 回吐草稿、生成一条 GitHub 预填链接。那条链接打开的是 GitHub 自己的「新建 issue」表单，用户点了确认才算创建。想要「一键提交」，请拿 draft 去你自己的服务端调 GitHub API——不要把 PAT 传进浏览器。
• 预填链接有长度上限。 实务上整条 URL 超过约 8000 字符（GITHUB_URL_MAX_LENGTH）后会被浏览器/代理/邮件客户端截断，或被 GitHub 直接拒绝。此时组件不渲染「在 GitHub 上打开」按钮，改为提示 + 「复制 Markdown」。判据量的是整条 URL 而不是 body：中文按 UTF-8 百分号编码后一个字占 9 个字符，长标题一样能把额度吃满。
• 相关组件候选必须外部喂。 组件不会去 fetch llms.txt 或 registry —— 那是消费方的数据来源与缓存策略，同 ComponentPicker 的边界。不传 components 就不渲染该字段。
• `control: "markdown"` 会拉入 tiptap。 MarkdownEditor 依赖 @tiptap/*，体积不小。内置三套模板刻意全用 textarea，需要富文本时自己在模板里把某个字段改成 markdown。
• 不要给它套 `<form>` 期待自动提交。 组件本体刻意不渲染 <form>（它要能塞进 ModalForm 的表单里，嵌套 form 是非法 HTML）。弹层外的独立用法请用内置提交按钮或 apiRef.submit()。
• 模板的 `labels` 与组件的 `text` 别搞混。 前者是 GitHub 标签（进 draft.labels 与 URL 的 labels 参数），后者是界面文案覆盖。
• 界面文案默认跟随 locale。 不传 text 时全部文案取 ConfigProvider 的 locale（未包 Provider 回落内置中文），IssueReporterModal 的 modalTitle 同理。优先级是 text prop > locale > 内置兜底。注意模板自带的字段 `label` / `placeholder` 不在 locale 覆盖范围内——它们属于 templates 数据，要英文界面请连模板一起替换。
• 切模板不会清空同名字段。 值表跨模板共用，bug 与 feature 若都有 summary，切过去内容还在——这是有意的（避免误切模板丢内容），需要清空请调 apiRef.reset()。