垃圾React设计问题集中讨论/记录

[cyfung1031]

React 就是垃圾
React is Rubbish

[cyfung1031]

edd13c6

updateScriptList 的设计导致大量重绘处理

---

不对。更新了单一个 entry 后要更新整个list 是对的

9c67e4a

问题是这个 commit

    useEffect(() => {
      let isMounted = true;
      // 先从 cache 读取，避免重复请求相同 uuid 的 metadata
      Promise.all(
        script.map(async (item) => {
          let metadata = cache.get(item.uuid);
          if (!metadata) {
            const script = await scriptDAO.get(item.uuid);
            if (script) {
              metadata = script.metadata || {};
            }
            cache.set(item.uuid, metadata);
          }
          return { ...item, metadata: metadata || {} };
        })
      ).then((newScriptMenuList) => {
        if (!isMounted) {
          return;
        }
        updateScriptMenuList(newScriptMenuList);
      });
      return () => {
        isMounted = false;
      };
    }, [cache, script]);

即使 item reference 没改变，也会因为 return { ...item, metadata: metadata || {} }; 操作导致 React.memo 的记忆失败
令所有 item 重新 render

[cyfung1031]

提交了PR解決：

• [v1.3] 修正React重绘问题 （Popup） #1181

[cyfung1031]

关于 useMemo( ..., []) 的不变memo state,
我问了AI要不要放进 useEffect 的 deps
它这样回我

---

From React’s perspective (and eslint-plugin-react-hooks):

If a value is used inside an effect, it should be in the dependency array.

---

Option 1. ChatGPT的看法是 "Keeps exhaustive-deps happy", "Zero runtime downside"

---

Option 2. 这个好像不被 CodFrm 接受，所以还是用 useMemo 算了

[cyfung1031]

因为 cacheMap 是 const不变， 用于改变状态的function 可以抽出来，不需要在 React元件定义里纠缠
見 366f79e

[cyfung1031]

在卡片模式的ScriptCard有同样的重绘问题！

从下而上一直推， 暂时估计 filterScriptList 出问题

React.memo 中的参考对比是没改变
但仍然发生全列表重绘
原因不详

---

發現了 hooks.tsx 有一些介乎於 React元件定義 和 一般function 兩者之間的奇怪東西
應該是這個了！

[cyfung1031]

好，我找Gemini幫我分析了

---

在提供的代码中，性能瓶颈确实主要集中在 hooks.tsx。

问题分析

1. 对象引用频繁变更：在 useScriptList 的 useEffect 监听器（如 scriptRunStatus, enableScripts）中，你使用了 newList[index] = { ...list[index], runStatus }。虽然这符合 React 的不可变原则，但由于 scriptList 是 useScriptSearch 的核心依赖，一旦 scriptList 的引用改变，useScriptSearch 内部庞大的 useMemo（计算 filterItems）和 useEffect（执行过滤逻辑）都会重新运行。
2. useScriptSearch 逻辑过重：该钩子负责了侧边栏统计（Count）、标签解析、分类过滤以及关键词搜索。每当任何一个脚本的状态（如 runStatus）改变，它都会重新遍历整个数组并生成全新的 filterScriptList。
3. 渲染链条断裂：在 ScriptCard.tsx 中，虽然你使用了 React.memo，但因为父组件传递的 filterScriptList 里的对象是展开生成的全新对象（{...item}），导致 prevProps.item === nextProps.item 始终为 false，从而触发所有卡片重绘。

---

修改方案：优化 hooks.tsx

我们要引入 稳定的对象引用 和 细粒度的更新。

1. 优化 useScriptList 的状态更新逻辑

避免在更新状态时重排整个列表。

// hooks.tsx

// 修改 updateScripts 逻辑，确保只在数据真正改变时才替换对象
const updateScripts = (uuids: string[], data: Partial<ScriptLoading>) => {
  const set = new Set(uuids);
  setScriptList((list) => {
    let hasChanges = false;
    const newList = list.map((script) => {
      if (set.has(script.uuid)) {
        // 检查数据是否真的变了，避免无谓的引用替换
        const isDifferent = Object.keys(data).some(
          (key) => (script as any)[key] !== (data as any)[key]
        );
        if (isDifferent) {
          hasChanges = true;
          return { ...script, ...data };
        }
      }
      return script;
    });
    return hasChanges ? newList : list;
  });
};

2. 重构 useScriptSearch（计算与统计分离）

将“统计侧边栏数量”和“列表过滤”逻辑拆分。侧边栏统计只在脚本增删或重要状态改变时运行，而不应在 UI 交互时反复计算。

export function useScriptSearch() {
  const scriptListManager = useScriptList();
  const { scriptList } = scriptListManager;
  
  // 1. 只有当脚本数量或核心状态改变时，才重新计算侧边栏统计信息
  // 这里可以对 scriptList 进行哈希校验或仅观察关键字段
  const statsDependency = useMemo(() => 
    scriptList.map(s => `${s.uuid}-${s.status}-${s.runStatus}`).join(','), 
    [scriptList]
  );

  const filterItems = useMemo(() => {
    // ... 保持原有的 statusItems, typeItems 等逻辑，但使用 statsDependency ...
    // [逻辑同你之前的代码，但依赖项改为 statsDependency]
  }, [statsDependency, sidebarOpen, t]);

  // 2. 优化过滤逻辑：将过滤函数持久化
  const filterFuncs = useMemo(() => {
     // ... 保持原有逻辑 ...
  }, [selectedFilters, tagMap, originMap]);

  // 3. 结果缓存：使用 useMemo 代替 useEffect + useState
  // 这样可以减少一次渲染周期（setState 会触发二次渲染）
  const filterScriptList = useMemo(() => {
    let list = scriptList.filter((script) => filterFuncs.every((fn) => fn(script)));
    
    // 如果有关键词搜索，这里建议将 SearchFilter 改为同步或在外部处理
    // 如果必须异步，保持当前的 useEffect 逻辑，但确保 filterList 引用稳定
    return list;
  }, [scriptList, filterFuncs]);

  // ... 剩余代码
}

---

修改方案：优化渲染（ScriptCard.tsx）

在 ScriptCardItem 的 memo 比较函数中，由于 ScriptLoading 包含 actionLoading 等 UI 状态，我们需要更精准的对比。

// ScriptCard.tsx

export const ScriptCardItem = React.memo(
  (props: ScriptCardItemProps) => {
    // ... 原有代码 ...
  },
  (prev, next) => {
    // 只有核心业务数据或加载状态改变时才重绘
    return (
      prev.item.uuid === next.item.uuid &&
      prev.item.status === next.item.status &&
      prev.item.runStatus === next.item.runStatus &&
      prev.item.actionLoading === next.item.actionLoading &&
      prev.item.enableLoading === next.item.enableLoading &&
      prev.item.favorite === next.item.favorite // 注意 favorite 的引用
    );
  }
);

核心建议总结

1. 减少 Spread 操作：在 useScriptList 的事件监听里，不要随意 {...script}，除非对应的属性（如 runStatus）真的变了。
2. 使用 useMemo 过滤：不要在 useEffect 里 setFilterScriptList，这会导致“列表更新 -> 触发 Effect -> 修改 FilterList -> 再次渲染”的链路。直接在渲染期间用 useMemo 计算结果。
3. 稳定 Context 值：如果 AppContext 里的 subscribeMessage 每次渲染都返回新函数，会导致 useEffect 卸载重连，务必检查。

你要不要我针对 hooks.tsx 的异步搜索部分提供一个更完整的同步+异步结合的重构版代码？

[cyfung1031]

确认整个 state 丢失了

[cyfung1031]

确认此为 DndContext / SortableContext 重绘导致

[cyfung1031]

最终确认了是 ScriptCard没使用 DraggableRow 和 DragHandle 导致

[cyfung1031]

提交了PR解決：

• [v1.3] 修正React重绘问题 （ScriptCard & ScriptTable） #1182

[CodFrm]

你太极端了，React确实很容易触发 re-render，需要自己手动使用memo之类的方法去进行优化（React 19 引入了 React Compiler，能在编译阶段自动分析代码依赖，自动加上 memoization，不知道值不值得一试），这点甚至是React的设计哲学，比Vue更精准的控制，但这大多数都不是框架的问题，通常都是业务代码的问题，这点我只能承认我写的代码垃圾，用好React确实需要有比Vue更强的编码能力。

React有庞大的生态，全球顶级产品都在用 React，说明它经得起实战考验，并且也有RN、next.js等多平台框架，不能因为一点而否定全盘。

[cyfung1031]

做个记录

我知道看起来是多余的操作
但React就是要一直做这些麻烦事
某天你从这个 State framework 走向 signal framework 的话
你就会发现世界有多美好

---

这是一个非常经典且硬核的 React 性能优化问题。对于不了解 React 的人来说，这段代码看起来确实是“脱裤子放屁”——明明可以直接一步到位，为什么要先转成字符串，再切回数组？

简单来说：这是一种“空间换时间”和“牺牲局部逻辑简洁，换取整体渲染性能”的黑科技技巧。

以下是详细解释：

---

核心矛盾：React 的“肉眼”与“内存地址”

在 React 中，系统判断“数据是否变了”并不是挨个看数组里的内容，而是看这个数组在内存里的地址（引用）。

1. 直接用 .map 的问题

当你写 const sortableIds = scriptList.map(...) 时，每一次 React 尝试更新界面（哪怕只是改了一个脚本的名字或者开关了一下状态），.map 都会在内存中创建一个全新的数组对象。

• 旧数组地址： 0x001 (内容: ["A", "B"])
• 新数组地址： 0x002 (内容: ["A", "B"])

虽然内容一模一样，但 React 认为 0x001 !== 0x002。这会导致依赖 sortableIds 的所有拖拽组件强制全量重新渲染，造成严重的卡顿。

---

为什么代码要多此一举？

我们来看看代码里的“骚操作”：

// 1. 先把 ID 连成一个长字符串
const sortableIdsString = list?.map((s) => s.uuid).join(",") || "";

// 2. 只有当“字符串内容”变了，才重新生成数组
const sortableIds = useMemo(() => sortableIdsString?.split(",").filter(Boolean), [sortableIdsString]);

这里的奥秘在于：字符串是“值类型”

在计算机里，两个一模一样的字符串（例如 "id1,id2"）被认为是完全相等的。

1. 第一步（生成字符串）： 即使 list 里的某个脚本改了颜色，只要 uuid 的顺序和内容没变，生成的 sortableIdsString 就永远是同一个字符串。
2. 第二步（记忆化）： useMemo 是 React 的缓存机制。它会盯着 sortableIdsString。

• 如果字符串没变，它就直接把上次那个数组的内存地址丢回去。
• 这样，下游的拖拽插件（dnd-kit）拿到的永远是同一个内存地址。

---

形象比喻：超市理货员

想象你在管理一个超市货架（SortableContext），你需要一份货品清单（sortableIds）。

• 方案 A (直接 map)： 每次哪怕只是换个标签，理货员都会重新抄一份清单给你。你看到新纸条，就以为货架全乱了，得把所有货品搬下来重新摆一遍。（费力，卡顿）
• 方案 B (代码里的做法)： 理货员把清单内容念成一句话。只要这句话没变，他就把上一次那张纸条原封不动递给你。你一看纸条还是那张，就知道货架位置没动，不用折腾。（省力，流畅）

---

总结：为什么要这么改？

虽然多了字符串拼接和拆分的计算量，但这种计算在 CPU 面前是微秒级的。而它带来的好处是巨大的：

1. 防止“误报”： 只有当脚本的顺序真的发生变化，或者删减了脚本时，sortableIds 的引用才会变。
2. 拖拽性能： 拖拽列表通常非常重。如果用户只是点个开关，却触发了整个拖拽系统的逻辑重算，页面会明显“掉帧”。
3. 稳定性： 确保了 dnd-kit 这个库内部的对比逻辑更高效。

结论

这是为了让 React “死心”，告诉它：只要 ID 顺序没变，这就是同一个数组，你别瞎忙活去重新渲染拖拽组件了。

---

[CodFrm]

https://github.com/millionco/react-doctor

https://github.com/aidenybai/react-scan

发现了几个react质量检查的项目，感觉可以试试

[cyfung1031]

Vue 3.x 上 4.x 也不是什么难事
但 React 15 -> 16 -> 17 -> 18 -> 19 每一个都是考验...

我觉得有AI辅助，交给AI做最好的UI设计和方案就好，不用纠结于技术层面
总之用 React 就是心力交瘁 ...
有人提出了 Preact 但最后没成功
Vue 也有好多方案。 Svelte 还有我最爱的 Solid 都提供了原生效能但主流太强了
（SolidJS 已经是走到极限级别，但都没能动摇 React， 那就表示根本不会有同类似的 framework / library 可以改变业界）

我觉得现在有 AI，大家应该会减少关注前端技术开发，反正 AI 都会自动选最好的
即使是 React，只要不是人类写出来，应该不会出现以前那些效能缺陷

可以的话让 AI 直接用 React 19 来开发吧
React 19 用了全新技术，会快得多