remote

Overview ¶

Package remote demonstrates the full windowed-source loop: pkg/source coordinating a sparse pkg/table over a real paged HTTP API.

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 250ms of latency so the seams are visible. 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.

The loop, in this file:

Init            → src.Init()            → RequestMsg
RequestMsg      → fetch (a tea.Cmd)     → fetchedMsg
fetchedMsg      → src.Deliver + SetWindow
SetWindow       → ViewportChangedMsg    → src.Viewport → RequestMsg?
QueryChangedMsg → src.SetQuery          → RequestMsg

The filter and the sort are answered by the source, not by the table: FilterRemote / SortRemote mean the table reports what the user asked for and displays whatever comes back. 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 screen has to handle a status code, which is what a screen talking to anything real must do.
• Replies can arrive out of order. src.Deliver's generation check drops a page answering a query the user has already moved past — 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, and the usual j/k/g/G/^u/^d scroll through all 5,000 logical rows.