Repository navigation
perf(ui): the book reads payroll lines in one read on the web (#949) - #951
Merged
Merged
Conversation
Co-Authored-By: Claude <noreply@anthropic.com>
…s a fix (#949) Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
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.
What & why
Closes #949.
On the web,
getProposalDetail(id)reads the vault's whole proposal list and picks one proposal from it, with no cache. The Ledger called it once per payroll in three places: the book by beneficiary, opening a payroll row, and the export. On a vault with many payrolls that is N reads of the whole list in sequence.readPayrollLines(ids)(new,ui/src/payroll-lines.ts) gives the Ledger the lines of the payrolls it asks for:getBookWithLines(no second "book with lines" reader);getBookWithLinesstops at the newest 12 settled payrolls on the bridge, which the Ledger cannot afford).What the Ledger shows is unchanged: the book by beneficiary keeps only payrolls with lines and does not ask again until reopened; a payroll row that answered no lines shows nothing (not "loading"); the export uses an empty list for a payroll that did not answer. One difference on the bridge: the book by beneficiary now stores the payrolls' lines when all are read, rather than one by one; the final state is the same.
Tests:
ui/src/payroll-lines.dom.test.ts: through the real reader with a counted fetch: 20 payrolls on the web = 1 fetch; 15 on the bridge = 15 detail reads; an empty payroll answers[], an unreadable book answers nothing; a source pin that the Ledger no longer callsgetProposalDetail.ui/src/ledger-reads.dom.test.tsx: the real Ledger: on the web, the book by beneficiary and the export each add exactly one read of the proposals (against the previous Ledger: 21); on the bridge, 20 detail reads each, past the cap.Follow-up worth an issue: the bridge's per-id loop now exists in
getBookWithLines(capped, for the proposal screen's note) and inreadPayrollLines(uncapped); movingreadPayrollLinesintoapi.tsand havinggetBookWithLinesuse it would leave one loop.Verify-before-finishing checklist
cargo fmt --check+cargo clippy -- -D warnings: not applicable (no Rust change)cargo test: not applicableui/: lint + vitest (263 files, 3034 tests) +tscpasstype(scope): descriptionCo-Authored-By: Claude <noreply@anthropic.com>, no session link