前端UI组件【免费下载链接】react-grid-layoutA draggable and resizable grid layout with responsive breakpoints, for React.项目地址https://gitcode.com/gh_mirrors/re/react-grid-layout点击查看免费下载本文以 react-grid-layout 仓库内置的.claude/skills/fix-issue.md技能文档为骨架讲解如何规范、可靠地修复该开源项目的 GitHub issue从理解问题、定位根因、测试先行TDD到最小化修复、验证、提交 PR 并最终合并的完整七阶段流程。读完本文你将掌握一套可复用的开源协作修复流程并理解 react-grid-layout 的代码分层、测试组织方式与常见 Bug 模式能够独立处理该仓库的 issue 并保证测试覆盖。一、文档定位与适用场景仓库根目录下有一个.claude/skills/fix-issue.md它定义了/fix-issue issue-number这一技能针对 react-grid-layout 的任意 GitHub issue以完整测试覆盖为前提进行分析与修复。它不是一篇泛泛的贡献指南而是一份遇到 issue 后照此执行的精确操作手册其核心原则可以概括为三点先理解后动手拿不到可复现信息或需求不明确时宁可停下也不盲目修改测试先行先写一个能复现 Bug 且必然失败的测试再写修复代码TDD最小化改动 全量验证只修复必要内容随后跑通全量测试、lint 与格式化。该技能文档面向的仓库当前版本为2.2.4见 package.json其代码分层清晰src/core纯 TypeScript 算法层、src/reactReact 组件与 hooks 层、src/legacyv1 API 兼容层。文档中大量细节目录结构、测试目录、命令都能在仓库中得到印证。二、前置条件工具链准备执行该工作流需要以下命令行工具缺一不可工具用途文档中的典型命令ghGitHub CLI查看 issue、检查 PR 状态、创建与合并 PRgh issue view issue-numbergit分支管理、提交、推送git checkout -b fix/issue-n-descnode/npx/yarn运行测试、lint、格式化yarn test、yarn lint、yarn fmtmake调用仓库 Makefile 定义的便捷任务make test-watch文档给出的 watch 模式入口其中yarn test、yarn lint、yarn fmt三个命令分别对应 package.json 中的scripts.test、scripts.lint、scripts.fmt它们最终转发到 Makefile 中的testenv NODE_ENVtest npm exec -- jest --coverage与linteslint --ext .js,.jsx,.ts,.tsx目标。也就是说yarn test实际等价于带覆盖率统计的 jest 全量运行这是后续验证阶段的重要背景。三、Phase 1理解 Issue不明确就不动手1. 拉取 issue 详情gh issue view issue-number2. 分析问题属性拿到详情后需要回答四个关键问题它们决定了后续修复方向这是 Bug 还是功能请求功能请求若没有明确需求边界不应贸然实现是否存在可复现样例如 CodeSandbox 链接没有复现路径的 Bug 无法用测试锁定涉及哪个组件 / hook决定你该去src/react/components/、src/react/hooks/还是src/core/里找代码属于哪种 API 层的问题是 v2 API、legacyv1API还是核心算法本身的问题。3. 明确不可动手的边界文档特别强调以下四类 issue 应当停下并说明原因而不是尝试修复需求不清晰的功能请求feature requests without clear requirements无法复现的问题cannot be reproduced只是提问、并非 Bug 的 issuequestions, not bugs已经被修复过的问题already fixed。这一条是质量底线开源仓库中大量 issue 其实是重复报告或使用问题判断是否 actionable本身也是修复工作的一部分。四、Phase 2调查代码库并定位根因1. 定位相关代码文档给出的手段是用 Grep/Glob 找到相关文件阅读受影响的组件 / 函数理解当前行为追踪导致 Bug 的代码路径留意其他位置是否存在同模式隐患。2. 结合仓库源码理解代码分层fix-issue.md的 Repository Context 部分精确对应仓库实际目录结构这是定位问题的地图目录职责仓库印证src/core/纯 TypeScript 算法不含 React 依赖包含 calculate.ts、collision.ts、compactors.ts、constraints.ts、layout.ts、responsive.ts 等可从子路径独立引用src/react/components/React 组件GridLayout、GridItem、ResponsiveGridLayout 等见 GridLayout.tsx、GridItem.tsx、ResponsiveGridLayout.tsx、WidthProvider.tsxsrc/react/hooks/React hooksuseContainerWidth、useResponsiveLayout、useGridLayout见 useContainerWidth.ts、useResponsiveLayout.ts、useGridLayout.tssrc/legacy/v1 API 兼容包装层见 ReactGridLayout.tsx、ResponsiveReactGridLayout.tsx、WidthProvider.tsxtest/spec/Jest 测试见下文测试组织3. 从测试反推行为契约文档要求Review related tests即检查test/spec/中的既有测试理解相似功能是如何被测试的。仓库的 test/spec/ 目录提供了大量范例可按主题对号入座布局与核心算法core-functions-test.ts、compactors-test.ts、static-compaction.test.ts、fast-compactor-test.js、fast-horizontal-compactor-test.js、wrapCompactor-test.ts约束与拖拽缩放constraints-test.ts、resize-constraints-test.tsx、resize-event-test.tsx、touch-drag-props-test.tsx响应式responsive-generation-test.ts、responsive-settle-test.tsx、responsive-seeding-test.tsx、responsive-gap-collapse-test.tsxhooks 与组件hooks-test.tsx、typescript-components-test.tsx、lifecycle-test.js、backcompat-test.js拖放与滚动drop-alignment.test.ts、edgeScroll-test.ts、touch-drop-test.tsx、subpixel-width-test.tsx五、Phase 3先写失败测试TDD 核心这是整个工作流中最关键的一步文档用CRITICAL强调Always write the test BEFORE the fix.1. 编写复现测试的规范把测试加到test/spec/下合适的测试文件中对应问题所属模块测试必须在无修复时失败MUST fail without the fix测试中必须用注释引用 issue 编号// #issue-number。这一issue 编号注释约定在仓库中已经成为惯例。例如 hooks-test.tsx 中有// #1959 - Verify cancelAnimationFrame is called on unmount、// #2213 - Custom compactors should be calledbackcompat-test.js 中有#1959 - WidthProvider should defer ResizeObserver updates、allowOverlap (#2205)drop-alignment.test.ts 直接以PR #2167 - Drop item alignment、Drop position with scroll offset (#2143)命名edgeScroll-test.ts 以edgeScroll (#2232)命名。这说明**用注释 / describe 名携带 issue 编号正是该仓库维护者认可的实际做法**写测试时直接沿用即可。2. 验证测试确实失败NODE_ENVtest npx jest --testPathPatternstest-file如果测试直接通过说明测试无效没有真正复现 Bug必须修订测试失败现象应当与报告的 Bug 行为吻合而不是因环境报错而失败。该命令与 package.json 中scripts.test:matchNODE_ENVtest npx jest --testPathPatterns一致可放心使用。3. 理解测试环境避免写出假失败为了让测试在 JSDOM 下稳定运行仓库通过 test/util/setupTests.js 做了一组环境垫片了解它们有助于写出可靠的测试TimSort 排序垫片Node 12 起内置Array.prototype.sort从 QuickSort 改为 TimSort为保持测试确定性用timsort包统一替换offsetParent垫片拖拽代码依赖offsetParentJSDOM 中不可用改为返回parentNode可控的ResizeObservermock所有 observer 被记录到global.__resizeObservers__并提供triggerResize(width, height)辅助函数手动触发尺寸变化这正是#1959修复依赖的测试设施同步执行的requestAnimationFramemock回调同步执行以避免时序问题注释中直接引用了#1959同时cancelAnimationFrame为 no-op。另外package.json 的 jest 配置值得注意testMatch限定test/spec/下的.js/.ts/.tsx测试环境为jsdom并设定了全局覆盖率门槛语句 65%、分支 60%、函数 65%、行 65%。这意味着你的新测试连同被测代码必须把整体覆盖率维持在该门槛之上否则yarn test会因覆盖率不达标而失败。六、Phase 4实现最小化修复测试确认失败后进入修复阶段只做解决 issue 所需的最小改动不要顺手重构无关代码不要添加多余功能若修复逻辑不直观务必补写注释解释为什么这样修能生效并引用 issue 编号重新运行单测确认从失败变为通过NODE_ENVtest npx jest --testPathPatternstest-file仓库源码中可以找到若干与文档常见 Bug 模式一一对应的真实修复痕迹可作为最小化修复的范例参考拖拽阈值ReactGridLayout.tsx 中将 legacy 的dragConfig.threshold固定为0并注释说明v2 API 默认 3px 阈值fixes #1341, #1401——即为了让 v1 兼容层保持旧行为只在该层覆盖这一个配置而不是改动 v2 默认值RAF 延迟 ResizeObserver 更新#1959的修复在 hooks 层以requestAnimationFrame延迟 ResizeObserver 的 state 更新并在卸载时取消挂起的 RAF对应 useContainerWidth.ts 与 hooks-test.tsx 中的卸载取消测试自定义 compactor 接入#2213使useGridLayout接受外部compactor并在初始化与拖拽时调用compactor.compact()对应 useGridLayout.ts 中UseGridLayoutOptions.compactor字段与 hooks-test.tsx 中accepts custom compactor、calls custom compactor.compact() during drag两个测试。七、Phase 5全量验证修复通过单测后必须在提交前完成三重验证文档给出了准确命令# 1. 全量测试含覆盖率统计 yarn test # 2. lint 检查 yarn lint # 3. 格式化 yarn fmt任何一项失败都必须先解决再继续。从 package.json 可以看到yarn test→make test→env NODE_ENVtest npm exec -- jest --coverage全量测试 覆盖率yarn lint→make lint→eslint --ext .js,.jsx,.ts,.tsxyarn fmt→prettier --write .。此外 Makefile 还提供了开发友好的变体# 所有测试带覆盖率 yarn test # 指定测试文件文档给出的关键命令 NODE_ENVtest npx jest --testPathPatternspattern # Watch 模式 make test-watchmake test-watch对应 Makefile 中的env NODE_ENVtest npm exec -- jest --watch适合修复过程中反复迭代。八、Phase 6提交与创建 PR验证全绿后按以下步骤提交。分支命名规范为fix/issue-issue-number-short-description# 1. 创建分支 git checkout -b fix/issue-issue-number-short-description # 2. 提交消息需包含根因与修复说明 git add files git commit -m fix: description (#issue-number) Explanation of root cause Explanation of fix # 3. 推送并创建 PR git push -u origin branch-name gh pr create --title fix: description (#issue-number) --body ## Summary Fixes #issue-number Root cause explanation ### The fix Fix explanation ## Test plan - [x] Added test that fails without fix - [x] Test passes with fix - [x] All existing tests pass注意 PR 模板的三个勾选项与工作流的测试先行原则一一对应新增测试在修复前失败、修复后通过、既有测试全部通过——这是评审者最关心的证据链。提交信息中根因解释 修复解释双段落结构也与文档fix 提交必须讲清楚 WHY的要求一致。九、Phase 7等待 CI 并合并# 1. 阻塞等待 CI 全部通过 gh pr checks pr-number --watch # 2. 若检查失败修复问题后重新推送重复 Phase 4/5 # 3. 全绿后以 squash 方式合并并删除分支 gh pr merge pr-number --squash --delete-branch # 4. 切回主干并同步 git checkout master git pullsquash合并会把整个 PR 压缩为单个提交保持master历史干净——这与提交规范中一条 fix 提交对应一个 issue的风格一致。十、仓库关键目录与常见 Bug 模式排错路线图fix-issue.md的 Repository Context 不仅给出目录地图还总结了该仓库最常出现的三类 Bug。结合源码可以进一步理解其成因与排查思路模式 1无限重渲染循环Infinite re-render loops典型成因useCallback/useEffect依赖项中引用了会在回调执行期间变化的状态。修复方向改用 ref 访问当前值避免因读取触发重渲染。源码印证useGridLayout.ts 的状态管理完全围绕useStateuseCallbackuseEffectuseRef展开并大量使用fast-equals的deepEqual做深层比较——这正是为了避免引用变化导致副作用反复触发这一经典陷阱。模式 2布局不更新Layout not updating典型成因缺少深相等比较或 props 未正确同步到内部 state。修复方向引入深层相等检查确认 props → state 的同步路径。源码印证useGridLayout.ts 直接从fast-equals导入deepEqual参与状态同步判断ReactGridLayout.tsx 则把 v1 的扁平 propscols、rowHeight、margin、compactType等转换为 v2 的组合式接口gridConfig、dragConfig、resizeConfig、dropConfig再传给新组件——任何一步映射遗漏都会表现为布局不按预期更新。模式 3legacy API 兼容问题Legacy API issues典型成因扁平 props 到 v2 组合接口的映射不正确或给定 props 下选错了 compactor。修复方向检查 props 映射表与 compactor 选择逻辑。源码印证ReactGridLayout.tsx 中有两个典型细节compactor 选择通过getCompactor(compactType, allowOverlap, preventCollision)来自 compactors.ts统一决策并处理已废弃的verticalCompactpropverticalCompact false时发出弃用警告并映射为compactType null约束组合isBounded为真时在defaultConstraints来自 constraints.ts基础上追加containerBounds否则使用默认约束。这份常见模式清单的价值在于遇到新 issue 时先对照这三类已知模式排除能大幅缩短定位时间同时它也提示legacy 层的任何改动都必须由 backcompat-test.js 这类行为契约测试守护——该文件头部明确写道这些测试验证公共 API 的实际行为契约任何一项在改动后失败都意味着破坏性变更。十一、提交前检查清单文档 Before Committing 部分要求提交前始终执行yarn lint yarn fmt结合上文完整交付前的自检清单应为测试文件位于test/spec/对应模块包含// #issue-number注释新测试在无修复时失败、有修复时通过失败行为与 issue 描述一致改动范围最小未触碰无关代码未引入新功能yarn test全量通过含覆盖率门槛语句 65%、分支 60%、函数 65%、行 65%yarn lint无错误yarn fmt完成格式化提交信息含#issue-number、根因与修复说明PR 描述含 Fixes # 与 Test plan 三个勾选项CI 全绿后以--squash --delete-branch合并总结.claude/skills/fix-issue.md本质上把一次高质量的 GitHub issue 修复拆解为理解 → 调查 → 测试先行 → 最小修复 → 全量验证 → 提交 PR → CI 合并七个可执行阶段并配套了精确到命令的实操规范。在 react-grid-layout 仓库中这套流程并非纸上谈兵test/spec/中大量以 issue 编号#1959、#2167、#2213、#2232等命名的测试、ReactGridLayout.tsx 中注明修复来源的阈值注释、以及 test/util/setupTests.js 为复现环境所做的垫片都是这套工作流被真实执行过的证据。对想要为该仓库贡献修复的开发者而言遵循此流程既能保证修复质量也能让维护者快速信任你的 PR。赞分享前端UI组件【免费下载链接】react-grid-layoutA draggable and resizable grid layout with responsive breakpoints, for React.项目地址https://gitcode.com/gh_mirrors/re/react-grid-layout点击查看免费下载相关推荐Exposed 项目 Bug 修复端到端工作流从 Issue 解析、失败复现测试到 PR 合并的完整实战指南Exposed 项目 Bug 修复端到端工作流从 Issue 解析、失败复现测试到 PR 合并的完整实战指南 本文基于 Exposed 仓库内建的 fix bORM后端数据存储XTuner 全流程微调 InternVL 多模态大模型数据准备、训练与官方权重转换指南XTuner 全流程微调 InternVL 多模态大模型数据准备、训练与官方权重转换指南 导读 本文基于 XTuner 仓库中 InternVL 配置目录 h前端UI组件问题描述问题描述 清晰描述问题现象包括预期行为与实际行为差异 复现步骤 1. 导入proto文件: example.proto 2. 输入请求参数: {id: 开发工具上一篇5分钟上手Node.js NLP从文本分析到情感识别的零代码指南下一篇GitHub_Trending/in/interviews代码重构与设计模式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考