fix(ui): keep one state for the transaction type filter, shared by both controls - #230
Merged
Merged
Conversation
…th controls The transactions view filters by type through TWO controls — the `#tx-tabs` strip (全部/消费/收益) and the 类型 column's `select.th-filter` (the six database values) — but the state was split: the tabs wrote a module-level `txTab`, the select wrote `txTable.filters.type`, and `loadTransactions` resolved them with a documented precedence, `const type = colType || (txTab === "all" ? "" : txTab)`. The column select therefore wins permanently: once it has a value, a tab click sets `txTab` and repaints nothing else, so the click is a NO-OP (the request still carries the column filter). And because the highlight was painted from `txTab` alone, the strip meanwhile claims a filter that is not the applied one — with the 类型 select on 赠送, the list shows gift rows while 全部 stays lit. This is one filtered concept with one state that must be the single source for the request parameter, the tab highlight, and the select: the fix deletes the second state (`txTab`) and routes both controls through `txTypeFilter()` (read) / `setTxTypeFilter()` (write — it also syncs the already-rendered select, since #148 stopped rebuilding the thead and the widget no longer follows the state by itself). When the effective value is not one of all/consume/earn (topup / withdraw / gift / expire), no tab claims to be active: lighting 全部 while the list holds gift rows would be the same lie in the other direction. Verified with a jsdom probe (real ui/index.html + js/api.js + data.js + i18n.js + app.js, only `fetch` stubbed) that drives the real controls and compares all three artifacts against ONE derivation, `wantTabs(type)` — never a literal, which would pass by accident whenever the stale highlight happens to spell it. A/B (baseline pinned to d1faab6 via `git show`; the driver aborts if the baseline equals the fix): pre-change 5/11 (red B2/B3/B4/B5/C1/C2), three wrong fixes each rejected — dead click 4/11, unsynced select 9/11, constant highlight 7/11 — fixed tree 11/11 with the built-in control A0 green in every leg.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
交易页的类型筛选有两套控件(顶部
#tx-tabs全部/消费/收益 + 「类型」列表头的select.th-filter,6 个库内值),状态却分成两份:tab 写模块级txTab,列筛选写txTable.filters.type,loadTransactions按固定优先级取filters.type || txTab⇒ 列筛选一旦出值就永久盖住 tab:txTab、重画高亮,请求仍带列筛选的值 ⇒ 这一点击什么都没发生;txTab画 ⇒ 列筛选选「赠送」时列表是赠送行,而「全部」仍然亮着。同一个筛选概念只能有一份状态。本改动删掉第二份(
txTab),两套控件都走txTypeFilter()(读)/setTxTypeFilter()(写,并同步已渲染的 select —— #148 之后表头不重建,控件不会自己跟上状态)。生效值不属于 all/consume/earn 时(topup / withdraw / gift / expire)没有任何 tab 自称生效:把「全部」点亮而列表只有赠送行,同样是在说谎。Related Issue
(无关联 issue;本轮为自测复现的缺陷修复)
Changes
ui/js/app.js:删除txTab;新增txTypeFilter()/setTxTypeFilter()作为唯一读/写入口;tab 高亮改由生效状态派生;tab 点击只写状态,重拉交给既有的筛选签名比对ui/index.html:app.js?v=20260914-7(cache-bust)ui/README.md:记录「一份状态、两套控件」的约定与冒烟测试注意点Tests
cargo test全部通过(235 passed,与改前一致)cargo fmt --check通过cargo clippy无新增 warning验收探针(jsdom,真
ui/index.html+ 四个真脚本,只 stubfetch)探针驱动真控件(真 tab 点击、真
select+ 真input事件),并把三个产物(请求参数 / tab 高亮 / select 的值)与同一个派生wantTabs(type)比较 —— 不用字面量,否则应用的高亮恰好拼对时会误绿。A/B(基线钉在
d1faab6,git show取改前文件;驱动在「基线 == 修复」时直接 ABORT,避免变成空对照):v0_origm_deadm_nosyncm_indlive内建阴性对照
A0(探针能看见已渲染的表格)在每一条腿都是绿的。如实记录一点:m_nosync的红集是m_dead的子集(回退「写状态」本身就包含了「不同步 select」),两者非互斥;互斥的是m_dead与m_ind。Checklist
fix/tx-type-filter-single-state)fix(ui): ...)