diff options
| author | Craig Jennings <c@cjennings.net> | 2026-06-05 01:38:35 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-06-05 01:38:35 -0500 |
| commit | 5940d7caf21f5c2b8e322a67f32657dace56fc9a (patch) | |
| tree | d5eb951bed71e2e25c7e45bd14e0fa5605e1c7ff /docs/saved-query-sync-spec.org | |
| parent | 3f491e73cdbdc03d652bce81fdfc68eabb313213 (diff) | |
| download | pearl-5940d7caf21f5c2b8e322a67f32657dace56fc9a.tar.gz pearl-5940d7caf21f5c2b8e322a67f32657dace56fc9a.zip | |
fix(views): make a server-side sort actually reorder the buffer
A server-side sort (updated/created) refetched with the new orderBy and merged the result, but the merge updates issues in place by id and never moves them, so the buffer kept its old order and the sort had no visible effect. I caught it dogfooding live: sorting My Open Issues updated-ascending then updated-descending rendered an identical order.
After the refetch I now reorder the buffer's issue subtrees to the fetched order. pearl--issue-id-ranks builds a LINEAR-ID to position map from the sorted result, and pearl--reorder-issue-subtrees takes an optional id-ranking and lays the subtrees out by it. The move is the same byte-for-byte subtree shuffle the client-side sort already uses, so unpushed edits survive. Re-checked live: updated-ascending now comes back the exact reverse of updated-descending.
Diffstat (limited to 'docs/saved-query-sync-spec.org')
0 files changed, 0 insertions, 0 deletions
