remote

Overview ¶

Package remote demonstrates a table over a real paged HTTP API, bound with pkg/remote: the screen writes the HTTP call and nothing else.

The server is demoapi, and it is a genuine http.Handler reached through a genuine *http.Client — the request is built, encoded, routed, answered and decoded. It holds 5,000 applications and only ever answers one page at a time, with a deliberate latency so the seams are visible — 250ms by default, and L cycles it up to 8s. Nothing about the table's 5,000 rows is real: it holds one 100-row window and draws "·" everywhere else, which is what you see for a moment when you scroll faster than the source answers.

What a slow source looks like, none of it written here: a committed filter or sort leaves the rows on screen, dimmed, with the border naming the query they answer and the one loading; [ ] s wait for a quiet moment before asking; scrolling waits until it settles; and every superseded request is cancelled — watch the output console (o) for each query's outcome.

The filter and the sort are answered by the server, not by the table. Type "region:eu-west" and it leaves here as "?region=eu-west" — Term.Title is the resolved column title, so a scoped term becomes a query parameter with no lookup on this side.

Two things a slice and a time.Sleep could not demonstrate, and which this crosses a request boundary to reach:

• A request can fail. Press "e" and the next fetch asks the server for a 503; the page function returns the error and the table says so.
• Replies can arrive out of order. A page answering a query the user has already moved past is dropped — and it can only be a real drop if a real slow reply really does land second.

Keys: / filters (enter commits — the request goes out then, not per keystroke), [ ] s sort, r refetches the current window, e arms one failure, L cycles the latency, and the usual j/k/g/G/^u/^d scroll through all 5,000 logical rows.