Add an interview mode filter to interview progress
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 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時間
- マージ済み PR(30日)
- 225
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 日以内に返信