Search is debounced 150 ms and crosses the bridge, and NotesQueryStore.view is
a linkedSignal that keeps the previous view during the reload — deliberately,
so the canvas does not blank on every keystroke.
The consequence is that between typing and the answer, the screen shows the old
result and says nothing about it. isLoading is !hasView && resource.isLoading():
true once, before the first view of the session, and false forever after. So
there is no state that means "this is stale, an answer is coming".
On the corpora this has been driven with, the round trip is short enough that
nobody would notice. ⚠️ That is exactly why this is filed as a suspicion and not
a defect: it has not been reproduced. query_notes fetches the whole corpus
and matches in Rust (#21), so the gap grows with the library, and the retained
view means it degrades silently — the canvas never looks busy, only wrong for a
moment.
Worth doing first
Measure it. #78 wants to know what each of the 38 commands costs; this is one of
the answers it would produce. If query_notes on a few thousand notes stays
under a frame or two, there is nothing to build and the ticket closes with a
number in it.
If it is worth building
The cheapest honest signal is on the count that now sits in the search field —
dimming it while the answer is in flight says "this number is about to change"
without moving anything. A spinner over the canvas would be worse than the
problem: it would flash on every keystroke.
Done when
Either a measurement says the gap is imperceptible and this is closed, or the
canvas admits when what it shows is one keystroke behind.
Search is debounced 150 ms and crosses the bridge, and
NotesQueryStore.viewisa
linkedSignalthat keeps the previous view during the reload — deliberately,so the canvas does not blank on every keystroke.
The consequence is that between typing and the answer, the screen shows the old
result and says nothing about it.
isLoadingis!hasView && resource.isLoading():true once, before the first view of the session, and false forever after. So
there is no state that means "this is stale, an answer is coming".
On the corpora this has been driven with, the round trip is short enough that⚠️ That is exactly why this is filed as a suspicion and not
nobody would notice.
a defect: it has not been reproduced.
query_notesfetches the whole corpusand matches in Rust (#21), so the gap grows with the library, and the retained
view means it degrades silently — the canvas never looks busy, only wrong for a
moment.
Worth doing first
Measure it. #78 wants to know what each of the 38 commands costs; this is one of
the answers it would produce. If
query_noteson a few thousand notes staysunder a frame or two, there is nothing to build and the ticket closes with a
number in it.
If it is worth building
The cheapest honest signal is on the count that now sits in the search field —
dimming it while the answer is in flight says "this number is about to change"
without moving anything. A spinner over the canvas would be worse than the
problem: it would flash on every keystroke.
Done when
Either a measurement says the gap is imperceptible and this is closed, or the
canvas admits when what it shows is one keystroke behind.