Add an interview mode filter to interview progress
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 78/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- html, javascript, rust
调研方向
Start with web/progress.js and the existing problemId filter tests in tests/browser/progress.test.js; then trace the filter wiring in web/app.js and the Filter attempts controls in web/index.html. Add mode filtering to the progress model and cover the UI behavior for account and device history in tests/browser/lobby.test.js. Done when Coding, Whiteboard, and All modes filter the attempts and related progress views, including when combined with existing filters.
由索引模型根据 Issue 内容生成。
描述
Observed behavior
Interview progress's "Filter attempts" section offers Problem, Difficulty, Language, and Duration filters (web/index.html:2041-2067), but no filter for interview mode. A Coding (editor) attempt and a Whiteboard attempt sit mixed together in Past attempts and the phase-score charts, even though they score different things (a whiteboard report scores "Board work", not "Coding", per the row labels in #604) and use an unrelated workflow: no editor, no code, no test runner.
Expected behavior
Candidates should be able to restrict Interview progress to only Coding attempts or only Whiteboard attempts. The selection should combine with the existing Problem, Difficulty, Language and Duration filters, and apply consistently to Past attempts, the phase-score charts, topic counts, and weakness summaries, the same way the existing filters already do. Selecting "All modes" should restore the current, unfiltered behavior.
Reproduction
- Complete at least one Coding-mode interview and one Whiteboard-mode interview.
- Open Interview progress.
- Observe that Filter attempts has no control to separate the two; Past attempts and the charts mix both kinds of attempt together.
Environment
- Source revision: 628237f.
Initial analysis
normalizeProgressEntry()inweb/progress.jsalready reads and normalizesinterviewModeper attempt (entry.interviewMode ?? entry.report?.interviewMode, throughlib.js'sinterviewMode()), so the value is already present on every normalized entry; no storage or server change is needed.progressModelFrom()'smatches(entry, key)helper (web/progress.js:178-189) already applies one generic filter toproblemId,difficulty,languageanddurationMin; adding"interviewMode"to that list follows the same one-line pattern as each existing filter.progressOptions()(web/progress.js:307-337) would need to also return the distinctinterviewModevalues present in history, the same way it already does fordifficulty,languageanddurationMin.web/index.html's Filter attempts fieldset (web/index.html:2041-2067) would need one more<select>, alongside Problem/Difficulty/Language/Duration.web/app.jswires each existing<select>throughsyncFilter()and folds its value into the filters object passed toprogressModelFrom()(web/app.js:1925-1943, 2607-2612); a Mode select would follow the same wiring, usinglib.js's existinginterviewMode()/modeIsWhiteboard()helpers for the two option labels ("Coding", "Whiteboard").
This mirrors the Problem filter added by #389 (PR #501, commit cb6678a), which used this same four-piece pattern (progressOptions, progressModelFrom's matches, the fieldset markup, and app.js's syncFilter wiring) for a different field.
Proposed change
Add a Mode select to Filter attempts, defaulting to "All modes", with "Coding" and "Whiteboard" options sourced from saved history. Combine it with the existing Problem, Difficulty, Language and Duration filters in progressModelFrom(). Apply the resulting attempts consistently to Past attempts, the phase-score charts, topic counts, weakness summaries, and the attempt count. Refresh the options when history changes; a mode with no remaining attempts drops out of the options the same way other filter values already do.
Validation plan
- Add model regression tests in
tests/browser/progress.test.jsforinterviewModefiltering alone and combined with the existing filters, mirroring theproblemIdtests already there. - Add UI interaction coverage in
tests/browser/lobby.test.jsfor both account and device history, selecting "Coding" / "Whiteboard" / "All modes" and asserting Past attempts and the charts narrow accordingly, mirroring the existing#progress-languagecoverage. - Run
./scripts/test.shand report results, including anything skipped.
- 主要语言
- Rust
- 星标
- 223
- 派生
- 148
- 平均合并
- 1 天 7 小时
- 30 天内合并 PR
- 225
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
sysprog21/codetrial 的其他 Issue
-
Show recorded scores in past attempt rows可能已有人在做 @liehcheng 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
sysprog21/codetrial#604 · 4 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 78/100
维护者通常 1 天内回复
-
Let candidates filter problems to their saved list可能已有人在做 @hszzt 今天认领。 未关闭
sysprog21/codetrial#616 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Report credits an inaccurate problem restatement as a strength可能已有人在做 @jserv 今天认领。 未关闭
难度 4/5 3-5 天 新手友好度 48/100
sysprog21/codetrial#613 · 2 条评论 ·
维护者通常 1 天内回复
-
Jim's compact card covers a text box's controls on an expanded Example drawing可能已有人在做 @Disesfgewu 今天认领。 未关闭
sysprog21/codetrial#609 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 sysprog21/codetrial 的全部 Issue
相似的 Issue
-
area:frontend kind:bug priority:p2 ready
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug priority: medium
难度 2/5 1-3 小时 新手友好度 68/100
storytold/vectorcraft#6143 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
rubys/roundhouse#1917 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
good first issue
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复