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

cyfung1031 · 2026-02-01T08:13:59Z

cyfung1031
Feb 1, 2026
Collaborator

React 就是垃圾
React is Rubbish

10BC0

cyfung1031 · 2026-02-01T08:14:08Z

cyfung1031
Feb 1, 2026
Collaborator Author

~~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

1 reply

cyfung1031 Feb 1, 2026
Collaborator Author

提交了PR解決：

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

cyfung1031 · 2026-02-01T09:40:22Z

cyfung1031
Feb 1, 2026
Collaborator Author

关于 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 算了

1 reply

cyfung1031 Feb 1, 2026
Collaborator Author

cyfung1031 · 2026-02-01T10:09:37Z

cyfung1031
Feb 1, 2026
Collaborator Author

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

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

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

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

5 replies

cyfung1031 Feb 1, 2026
Collaborator Author

好，我找Gemini幫我分析了

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

问题分析

对象引用频繁变更：在 useScriptList 的 useEffect 监听器（如 scriptRunStatus, enableScripts）中，你使用了 newList[index] = { ...list[index], runStatus }。虽然这符合 React 的不可变原则，但由于 scriptList 是 useScriptSearch 的核心依赖，一旦 scriptList 的引用改变，useScriptSearch 内部庞大的 useMemo（计算 filterItems）和 useEffect（执行过滤逻辑）都会重新运行。
useScriptSearch 逻辑过重：该钩子负责了侧边栏统计（Count）、标签解析、分类过滤以及关键词搜索。每当任何一个脚本的状态（如 runStatus）改变，它都会重新遍历整个数组并生成全新的 filterScriptList。
渲染链条断裂：在 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 的引用
    );
  }
);

核心建议总结

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

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

cyfung1031 Feb 1, 2026
Collaborator Author

确认整个 state 丢失了

cyfung1031 Feb 1, 2026
Collaborator Author

确认此为 DndContext / SortableContext 重绘导致

cyfung1031 Feb 1, 2026
Collaborator Author

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

cyfung1031 Feb 1, 2026
Collaborator Author

提交了PR解決：

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

CodFrm · 2026-02-01T11:05:11Z

CodFrm
Feb 1, 2026
Maintainer

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

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

0 replies

cyfung1031 · 2026-02-12T03:17:08Z

cyfung1031
Feb 12, 2026
Collaborator Author

做个记录

我知道看起来是多余的操作
但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"）被认为是完全相等的。

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

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

形象比喻：超市理货员

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

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

总结：为什么要这么改？

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

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

结论

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

0 replies

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

Uh oh!

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator

Replies: 5 comments · 7 replies

Uh oh!

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

问题分析

修改方案：优化 hooks.tsx

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

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

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

核心建议总结

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

cyfung1031 Feb 1, 2026 Collaborator Author

Uh oh!

Uh oh!

CodFrm Feb 1, 2026 Maintainer

Uh oh!

cyfung1031 Feb 12, 2026 Collaborator Author

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

1. 直接用 .map 的问题

为什么代码要多此一举？

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

形象比喻：超市理货员

总结：为什么要这么改？

结论

cyfung1031
Feb 1, 2026
Collaborator

Replies: 5 comments 7 replies

cyfung1031
Feb 1, 2026
Collaborator Author

cyfung1031 Feb 1, 2026
Collaborator Author

cyfung1031
Feb 1, 2026
Collaborator Author

cyfung1031 Feb 1, 2026
Collaborator Author

cyfung1031
Feb 1, 2026
Collaborator Author

cyfung1031 Feb 1, 2026
Collaborator Author

修改方案：优化 `hooks.tsx`

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

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

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

cyfung1031 Feb 1, 2026
Collaborator Author

cyfung1031 Feb 1, 2026
Collaborator Author

cyfung1031 Feb 1, 2026
Collaborator Author

cyfung1031 Feb 1, 2026
Collaborator Author

CodFrm
Feb 1, 2026
Maintainer

cyfung1031
Feb 12, 2026
Collaborator Author

1. 直接用 `.map` 的问题