Documentation
¶
Overview ¶
Package remote demonstrates the full windowed-source loop: pkg/source coordinating a sparse pkg/table over a simulated paged HTTP API.
The "server" holds 5,000 cities and only ever answers one page at a time, after a deliberate 250ms delay 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:europe" and the term arrives at the fake server already resolved to its column.
Keys: / filters (enter commits — the request goes out then, not per keystroke), [ ] s sort, r refetches the current window, and the usual j/k/g/G/^u/^d scroll through all 5,000 logical rows.
Index ¶
- func New(t theme.Theme) screen.Screen
- type Screen
- func (s *Screen) Help() []key.Binding
- func (s *Screen) Init() tea.Cmd
- func (s *Screen) IsCapturingKeys() bool
- func (s *Screen) Layout() layout.Node
- func (s *Screen) OnEnter(result any) tea.Cmd
- func (s *Screen) SetTheme(t theme.Theme)
- func (s *Screen) Title() string
- func (s *Screen) Update(msg tea.Msg) (screen.Screen, tea.Cmd)
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type Screen ¶
type Screen struct {
// contains filtered or unexported fields
}