Fix #1151: 修正按钮渲染逻辑，避免 render 阶段副作用，改用 JSX 条件渲染 & named slot

[cyfung1031]

概述 Descriptions

@CodFrm 以后AI做出来的PR 只会愈来愈多。Copliot找到的问题麻烦认真看待一下。
Codex在React元件定义里把state 做浅拷贝 再插React元件。。。太可怕了

变更内容 Changes

截图 Screenshots

---

为什么要做这个改动（背景）

在 React 中，render 阶段不应该产生副作用，也不应该修改已有的 state 或 props。
旧实现中，在函数组件的 render 过程中，通过 push 的方式向按钮数组中追加元素，这属于 在 render 阶段修改数组引用的副作用行为。

虽然目前代码仍然可以正常运行，但在以下场景中可能会产生问题：

• React Strict Mode 下 render 可能被执行两次，导致重复 push
• Concurrent Rendering 场景中行为不可预测
• 破坏 React 的 声明式渲染模型
• 增加潜在的渲染 Bug 和维护成本

因此，有必要对这部分代码进行重构优化。

这个 PR 做了什么改动

❌ 旧实现方式（不推荐）

在 render 阶段对数组进行操作，根据条件 push 新按钮：

const actionButtons = [...baseButtons];
if (netDiskType) {
  actionButtons.push(<Popconfirm ... />);
}

问题在于：

• render 阶段产生副作用
• 修改了数组结构
• 逻辑分散，不直观

✅ 新实现方式（推荐）

将按钮是否显示的逻辑直接写在 JSX 中，通过条件渲染控制：

<>
  {baseButtons}
  {netDiskType && netDiskName && (
    <Popconfirm ... />
  )}
</>

这样做的好处是：

• 不再修改任何传入的数组或 props
• 渲染逻辑一目了然
• 完全符合 React 的声明式写法

这次改动带来的价值

1. 避免 render 阶段的副作用

   • 不再使用 push、mutation 等操作
   • 更安全，符合 React 官方推荐实践

2. 逻辑更清晰、语义更直观

   • “什么时候显示解除绑定按钮”在 JSX 中一眼可见
   • 不需要追踪数组是如何被修改的

3. 减少潜在 Bug

   • 避免 Strict Mode 下的重复渲染问题
   • 对未来 Concurrent Rendering 更友好

4. 更容易维护和调试

   • JSX 即最终渲染结果
   • 按钮之间是明确的“兄弟关系”，而不是被动插入

总结

这次 PR 的核心思想是：

从「命令式、在 render 中修改数据结构」
转变为「声明式、在 JSX 中条件渲染 UI」

这是一个改动不大、但代码质量明显提升的重构：

• 风格更现代
• 可读性更好
• 潜在问题更少
• 更符合 React 在函数组件与 Hooks 时代的最佳实践

属于一次低风险、高收益的质量优化改动。

[cyfung1031]

改用 named slot
767e9d2

跟 1151 没直接关系。也不是什么大问题
但也不是什么大改动。所以直接塞在这PR了

---

虽然改用 children 才是最好最合理的选择，但考虑你日后可能会增加或改变这个 FileSystemParams 的设计，
只改成了 named slot

named slot 跟 children 一样是 JSX 模版
而不是像旧代码那样在props传复数的JSX模版 ( actionButtons: ReactNode[] )
render单一JSX模版和render多重JSX模版的分别 ( actions: ReactNode )

---

供参考的AI对话

---

对话1

你现在的 FileSystemParams 是通过 actionButtons prop 传一组按钮节点，想改成更符合 React 设计哲学的 children 组合式（composition）设计，这是一个很好的改动 👍

下面我按 「怎么改 + 为什么这样改 + 完整示例」 来说明。

---

一、设计目标

把：

<FileSystemParams actionButtons={[<Button ... />, ...]} />

改成：

<FileSystemParams>
  <Button ... />
  <Button ... />
  <Button ... />
</FileSystemParams>

这样做的好处：

• ✅ 更符合 React 组合（Composition）思想
• ✅ API 更直观、可扩展
• ✅ 不再限制只能是按钮（以后可以放 Tooltip / Dropdown / Divider 等）

---

二、修改 FileSystemParams 组件定义

1️⃣ props 定义：移除 actionButtons，使用 children

const FileSystemParams: React.FC<{
  preNode: React.ReactNode | string;
  onChangeFileSystemType: (type: FileSystemType) => void;
  onChangeFileSystemParams: (params: any) => void;
  fileSystemType: FileSystemType;
  fileSystemParams: any;
  children?: React.ReactNode; // 👈 新增
}> = ({
  onChangeFileSystemType,
  onChangeFileSystemParams,
  preNode,
  fileSystemType,
  fileSystemParams,
  children,
}) => {

❌ 删除 actionButtons

---

2️⃣ JSX 中直接渲染 children

把原来的：

{actionButtons}

改成：

{children}

完整关键片段：

<Space>
  {preNode}

  <Select
    value={fileSystemType}
    style={{ width: 120 }}
    onChange={(value) => {
      onChangeFileSystemType(value as FileSystemType);
    }}
  >
    {fileSystemList.map((item) => (
      <Select.Option key={item.key} value={item.key}>
        {item.name}
      </Select.Option>
    ))}
  </Select>

  {children} {/* 👈 这里 */}
  
  {netDiskType && netDiskName && (
    <Popconfirm
      title={t("netdisk_unbind_confirm", { provider: netDiskName })}
      onOk={async () => {
        try {
          await ClearNetDiskToken(netDiskType);
          Message.success(t("netdisk_unbind_success", { provider: netDiskName })!);
        } catch (error) {
          Message.error(`${t("netdisk_unbind_error", { provider: netDiskName })}: ${String(error)}`);
        }
      }}
    >
      <Button type="primary" status="danger">
        {t("netdisk_unbind", { provider: netDiskName })}
      </Button>
    </Popconfirm>
  )}
</Space>

---

三、父组件使用方式（改造后）

原来 ❌

<FileSystemParams
  actionButtons={[
    <Button key="save">...</Button>,
    <Button key="reset">...</Button>,
  ]}
/>

---

改成 children ✅

<FileSystemParams
  preNode={...}
  fileSystemType={fileSystemType}
  fileSystemParams={fileSystemParams}
  onChangeFileSystemType={setFilesystemType}
  onChangeFileSystemParams={setFilesystemParam}
>
  <Button
    type="primary"
    onClick={async () => {
      try {
        await FileSystemFactory.create(fileSystemType, fileSystemParams);
      } catch (e) {
        Message.error(`${t("account_validation_failed")}: ${e}`);
        return;
      }
      const params = { ...fileSystemParams };
      params[fileSystemType] = fileSystemParams;
      systemConfig.setCatFileStorage({
        status: "success",
        filesystem: fileSystemType,
        params,
      });
      setStatus("success");
      Message.success(t("save_success")!);
    }}
  >
    {t("save")}
  </Button>

  <Button
    type="primary"
    status="danger"
    onClick={() => {
      systemConfig.setCatFileStorage({
        status: "unset",
        filesystem: "webdav",
        params: {},
      });
      setStatus("unset");
      setFilesystemParam({});
      setFilesystemType("webdav");
    }}
  >
    {t("reset")}
  </Button>

  <Button
    type="secondary"
    onClick={async () => {
      try {
        let fs = await FileSystemFactory.create(fileSystemType, fileSystemParams);
        fs = await fs.openDir("ScriptCat/app");
        window.open(await fs.getDirUrl(), "_blank");
      } catch (e) {
        Message.error(`${t("account_validation_failed")}: ${e}`);
      }
    }}
  >
    {t("open_directory")}
  </Button>
</FileSystemParams>

---

四、进阶优化（可选）

🎯 如果你想更明确语义（推荐）

可以支持 named slots 风格：

<FileSystemParams
  actions={
    <>
      <Button>Save</Button>
      <Button>Reset</Button>
    </>
  }
>

或：

<FileSystemParams>
  <FileSystemParams.Actions>
    <Button>Save</Button>
  </FileSystemParams.Actions>
</FileSystemParams>

如果你有兴趣，我可以帮你设计一套 类似 Ant Design 的复合组件 API。

---

五、总结

✅ 最推荐方案：直接用 children

• 简单
• React 原生
• 扩展性最好

你现在这个组件非常适合做成 组合型组件，改完后 API 会明显更优雅 👍

如果你想进一步：

• 限制 children 只能是 Button？
• 自动包一层 <Space>？
• 支持 actions / footer / extra？

可以继续问我，我帮你设计一版更「组件库级别」的 API。

---

对话2

如果只选 一个「最好的」改动，在你当前这段代码和使用场景下，我的结论是：

把 actionButtons 改成「直接使用 children 的组合式设计」
不做 slot / 子组件 / 复杂抽象。

---

✅ 为什么这是「最好的」改动

1️⃣ 和你现在的复杂度 完全匹配

你的 FileSystemParams：

• 本质是一个 表单 + 操作区
• 操作按钮 强依赖父组件的业务状态
• FileSystemParams 本身 不需要知道这些按钮是什么

👉 这正是 children 最擅长的场景

---

2️⃣ API 变得「显而易见」

对比一下 👇

❌ 现在（actionButtons）

<FileSystemParams
  actionButtons={[
    <Button key="save" ... />,
    <Button key="reset" ... />,
  ]}
/>

问题：

• 多了一层「人为抽象」
• key 是被迫的
• 看代码时要在脑中「还原」这是 UI

---

✅ 改动后（children）

<FileSystemParams ...>
  <Button ... />
  <Button ... />
</FileSystemParams>

优点：

• 一眼就知道这是 UI 结构
• 和 <Space> / <Card> / <Form> 用法一致
• 不需要解释文档

---

3️⃣ 扩展性是「自然的」，不是「设计出来的」

未来你如果想：

<FileSystemParams>
  <Tooltip content="...">
    <Button>Save</Button>
  </Tooltip>

  <Dropdown ... />

  {isAdmin && <Button danger />}
</FileSystemParams>

👉 完全不用改组件本身

而 actionButtons: ReactNode[]：

• 会开始出现条件判断
• 数组拼接
• key 管理
• 可读性下降

---

4️⃣ 这是 React 官方推荐的设计方式

这属于 Composition over Configuration：

• ❌ props: { buttons: [...] }
• ✅ props.children

React / Ant Design / Arco / Radix UI 都是这样设计的。

---

🎯 最终推荐的最小改动（精简版）

FileSystemParams.tsx

interface Props {
  preNode: React.ReactNode | string;
  fileSystemType: FileSystemType;
  fileSystemParams: any;
  onChangeFileSystemType: (type: FileSystemType) => void;
  onChangeFileSystemParams: (params: any) => void;
  children?: React.ReactNode;
}

<Space>
  {preNode}
  <Select ... />
  {children}
  {netDiskType && ...}
</Space>

---

🚫 我不建议现在做的事情

除非你要做组件库，否则现在不值得：

• ❌ FileSystemParams.Actions
• ❌ actions / footer / extra props
• ❌ 限制 children 类型
• ❌ 过度抽象 slot

这些都会 增加维护成本，却几乎没有收益。

---

一句话总结

最好的改动：
把 actionButtons 删掉，直接用 children，到此为止。

这是性价比最高、最符合 React 思维、最不容易后悔的选择。

如果你愿意，我可以顺手帮你：

• 给这个组件写一段「为什么用 children」的注释
• 或帮你把整个设置页组件 API 顺一遍，让它更“组件库级别”

---

对话3: named slot 不好吗

很好的问题，而且你这个判断点 非常专业。
结论先给出来，再解释「什么时候好 / 什么时候不好」，最后给你 一版我认可的 named-slots 写法。

---

结论先行（重点）

named slots 并不是不好，但在你现在这个组件里：
❌ 性价比不如 children
⚠️ 只有在「结构稳定 + 语义明确」时才值得用

你这个 FileSystemParams：

• 结构 还在变化
• actions 强依赖业务
• 目前只有一个 slot（action buttons）

👉 现在用 named slots = 提前设计（over-design）

---

一、什么时候 named slots「是好的」？

下面这些条件 同时满足，named slots 就很香 👌

✅ 1. 插槽语义是稳定的

例如：

• Header / Footer
• Actions
• Extra
• Toolbar

这些 5 年后名字都不会变。

---

✅ 2. 组件有「布局责任」

组件需要 决定 slot 放哪、怎么排版：

Header  |  Actions
-------------------
Form content
-------------------
Footer

---

✅ 3. 会被多处复用

不是「某一个页面的组件」，而是 公共组件 / 组件库级别

---

二、为什么你现在不「急着」用 named slots？

❌ 1. 你现在只有一个 slot（actions）

<FileSystemParams actions={...} />

这和 children 没有本质区别，却多了：

• API 复杂度
• 心智负担
• 维护成本

---

❌ 2. 你的 actions 是「业务逻辑」，不是「结构」

例如：

• Save / Reset / Open
• 强依赖父组件 state
• FileSystemParams 本身不理解这些按钮

👉 结构型 slot 才适合 named slots
👉 业务型 UI 不适合

---

三、如果你「一定要用」named slots，正确姿势是什么？

如果你已经明确：

「这个组件以后一定会有明确的 Actions 区域」

那我推荐 Props-based named slots（最简单、最安全）

---

✅ 推荐方案：Props 形式的 Named Slot

1️⃣ 定义 Props

interface FileSystemParamsProps {
  preNode: React.ReactNode;
  fileSystemType: FileSystemType;
  fileSystemParams: any;
  onChangeFileSystemType: (type: FileSystemType) => void;
  onChangeFileSystemParams: (params: any) => void;

  actions?: React.ReactNode; // 👈 named slot
}

---

2️⃣ 使用时

<FileSystemParams
  preNode={...}
  fileSystemType={fileSystemType}
  fileSystemParams={fileSystemParams}
  onChangeFileSystemType={...}
  onChangeFileSystemParams={...}
  actions={
    <>
      <Button>Save</Button>
      <Button>Reset</Button>
    </>
  }
/>

---

3️⃣ 组件内部

<Space>
  {preNode}
  <Select ... />
  {actions}
  {netDiskType && ...}
</Space>

---

👍 这个方案的优点

• ✔ 语义清晰
• ✔ 不引入复杂模式
• ✔ 比 children 只多 一个 prop
• ✔ 随时可以退回 children（零破坏）

---

四、❌ 不推荐的「React 子组件式 slots」（现在）

<FileSystemParams>
  <FileSystemParams.Actions>
    ...
  </FileSystemParams.Actions>
</FileSystemParams>

原因：

• 需要解析 children
• TS 类型复杂
• 你这个组件 完全用不上这些能力
• 组件库级别才值得

---

五、我给你的最终建议（诚实版）

✅ 现在

👉 用 children

⏳ 以后如果出现这些情况

• 出现 Header / Footer / Extra / Actions
• 布局开始复杂
• 组件被 3+ 页面复用

👉 再升级为 named slots（props 版）

---

一句话总结

named slots 不不好，只是不适合“现在的你这个组件”。
最好的工程决策不是「最高级」，而是「刚刚好」。

如果你愿意，我可以：

• 帮你判断「什么时候该升级 slot」
• 或帮你设计一版 渐进式可升级 API（children → named slots）

[CodFrm]

确实没注意到😅，没想到本来就是数组，AI又给它套一层，还“机智”的加上了s。

[CodFrm]

看起来改成 children 是最好，最合理的，但是我也不记得我为什么要用这种方式了

[Copilot]

Pull request overview

本 PR 将 FileSystemParams 组件从命令式的数组操作模式重构为声明式的 JSX 子元素模式，消除了 render 阶段的副作用。

Changes:

• 将 FileSystemParams 的 actionButton 数组属性改为 children 插槽模式
• 将 preNode 属性重命名为更语义化的 headerContent
• 将网盘解绑按钮的条件渲染从 push 操作改为 JSX 条件渲染

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/pages/components/FileSystemParams/index.tsx	重构组件接口，将 actionButton 改为 children，将 preNode 改为 headerContent，网盘解绑按钮改用 JSX 条件渲染
src/pages/options/routes/Tools.tsx	更新 FileSystemParams 使用方式，按钮从数组属性改为子元素
src/pages/options/routes/Setting.tsx	更新 FileSystemParams 使用方式，按钮从数组属性改为子元素
src/pages/components/RuntimeSetting/index.tsx	更新 FileSystemParams 使用方式，按钮从数组属性改为子元素

[cyfung1031]

看起来改成 children 是最好，最合理的，但是我也不记得我为什么要用这种方式了

我沒看UI, 只看代碼改的。
其實也不是什麼大問題。不過順便改一下。
不是arrary的話兩種都可以。