feat: offer "refresh now" on header views too - #662
Conversation
The refresh entry was hidden wherever there was no query (`queryRef == null`), which is exactly the header views. That was right while refreshing meant re-running a query, but since #654 it also re-resolves the view definition — and for a header view the definition is the whole of what it shows: title, description and actions. So it now has something to refresh, and the entry is offered. "show query" and "full screen" stay hidden there; they really do need a query. The click takes the same path a query-form view takes: nothing on screen to rebuild, so the version is re-checked and the page left alone unless a newer version turns up, in which case the structure is refreshed and the page re-rendered as before. Verified live on the home page's four header views: the entry now appears (with the query-dependent ones still absent), the click issues a forced get-latest-version-of-np lookup for the header's nanopub, and the page does not re-render. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clicking "refresh now" answered with nothing visible on a header view, and for two reasons. The client-side indicator looks for a ".paneltitlerow" to put the spinner in, and a header view's title row is built differently — an h3 above a rule rather than an h4 — so no row was found and the panel was skipped entirely. Both row shapes are now recognised, with CSS placing the spinner in the header row the way it sits in a panel's: after the title, its auto right margin absorbing the space the title gives up, so nothing moves when it appears. The spinner is also held back 250ms, which is right for updates that happen as a side effect of typing or paging but wrong for one the user clicked for: these round trips take about a tenth of a second, so the delay alone left every "refresh now" silent. An explicitly requested refresh — the markup says which, via a class on the entry — now shows at once and stays 600ms, long enough to read. Verified live on the home page's header views and on a space page's regular and query-form views: the spinner appears ~5ms into the call where it previously never appeared at all (round trips measured 74-127ms), the title and the menu stay exactly where they were, it is gone afterwards, and the regular views still refresh in place. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Added the missing spinner (81c1d23). It was absent for two independent reasons. 1. The header title row was not recognised. The client-side indicator (nanodash.js) looks for a 2. The 250ms delay swallowed it anyway. That delay is right for updates that happen as a side effect of typing or paging — a spinner flashing on every keystroke is worse than none. It is wrong for one the user clicked for: these round trips measure 74–127ms, so the delay alone left every "refresh now" silent, on regular views too. An explicitly requested refresh — the markup says which, via a Measured live, driving the click headlessly:
No layout shift in either row shape (title left edge 15px and menu right edge 1385px, identical before and during), the spinner is gone afterwards, and regular views still refresh in place with no page re-render. Suite green: 1217 tests, 0 failures. |
Centring it in the row put it 6.8px above the middle of the title text: the row is taller than the text by the heading's 18.9px top margin, so the row's middle is not the text's. It now rides the row's baseline. An empty inline-block has no line box of its own, so its baseline is its bottom edge, which lands the circle on the title's baseline like a capital letter — no magic number, and it follows the heading if its size ever changes. Measured on the home page's header views: the spinner's middle is now 0.9px from the text's (was 6.8px above it) and its bottom sits on the baseline, 4.9px above the line box's bottom. Title and menu still do not move when it appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Follow-up to #657, closing the gap noted there.
Why
"refresh now" was hidden wherever a view display had no query (
queryRef == null) — which is exactly the header views (#572). That was right while refreshing meant re-running a query. Since #654 it also re-resolves the view definition, and for a header view the definition is the whole of what it shows: title, description, actions. So it does have something to refresh.What
ApiCache.clearCacheis guarded — a header view has no query reference to mark outdated.Verified live
Driven headlessly against the home page, which carries four header views (👥 Users, 🌎 Spaces, 🔍 Query, ✏ Publish):
show view · edit view display… · deactivate view display… · ↻ refresh now · show nanopub— the entry is there, and the query-dependent ones are still absent;get-latest-version-of-nplookup for the header's own nanopub (RAOOkASh…), so it really re-checks rather than doing nothing;Full suite green: 1217 tests, 0 failures. (
TemplateTest.invokeLookupApiForWikidatafailed once on the first run and passed on re-run — it asserts a live Wikidata lookup returns results, and is unrelated to this change.)Not covered: the escalation branch, i.e. what a header view does once its definition really has been superseded. Exercising it would mean publishing a new view version.
🤖 Generated with Claude Code