1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
|
# Watchers Reference
## Overview
Watchers connect Go's concurrency primitives to the go-tui event loop. A watcher is a goroutine that listens for something (a timer tick, a channel message) and queues a handler function on the main event loop when data arrives.
Because handlers run on the event loop, they can safely call `state.Set()`, `state.Update()`, and any other state mutation without synchronization. The watcher goroutine itself never touches UI state directly.
Watchers start when their owning component mounts (or when the element tree is set as the app root) and stop when the component unmounts or the app shuts down.
## Watcher Interface
```go
type Watcher interface {
Start(eventQueue chan<- func(), stopCh <-chan struct{})
}
```
All watcher types implement this single-method interface.
**Parameters:**
| Parameter | Type | Description |
|-----------|------|-------------|
| `eventQueue` | `chan<- func()` | The app's event loop queue. Send a `func()` to have it run on the main thread. |
| `stopCh` | `<-chan struct{}` | Closed when the watcher should shut down. Select on this to exit the goroutine. |
You rarely call `Start` yourself. The framework calls it during component mounting after walking the element tree with `WalkWatchers`. If you're building a custom watcher, implement this interface and launch a goroutine that selects on both your data source and `stopCh`.
```go
type myWatcher struct {
handler func()
}
func (w *myWatcher) Start(eventQueue chan<- func(), stopCh <-chan struct{}) {
go func() {
for {
select {
case <-stopCh:
return
case <-someCondition:
select {
case eventQueue <- w.handler:
case <-stopCh:
return
}
}
}
}()
}
```
The double-select pattern (first waiting for data, then trying to enqueue) prevents the goroutine from blocking on a full event queue when the app is shutting down.
## OnTimer
```go
func OnTimer(interval time.Duration, handler func()) Watcher
```
Creates a watcher that fires `handler` at a fixed interval. The handler runs on the main event loop.
Under the hood, `OnTimer` uses `time.NewTicker`. The ticker is cleaned up automatically when `stopCh` closes.
```go
func (s *stopwatch) Watchers() []tui.Watcher {
return []tui.Watcher{
tui.OnTimer(time.Second, func() {
s.elapsed.Update(func(v int) int { return v + 1 })
}),
}
}
```
The interval is approximate. The handler won't fire faster than the app's frame rate, and a backed-up event queue can introduce extra delay. For UI animation, intervals below 16ms (60fps) rarely produce visible improvement.
## ChannelWatcher
### NewChannelWatcher
```go
func NewChannelWatcher[T any](ch <-chan T, fn func(T)) *ChannelWatcher[T]
```
Creates a watcher that reads from a Go channel and calls `fn` for each value received. The handler runs on the main event loop, not in the goroutine that reads the channel.
When the channel closes, the watcher exits its goroutine. When `stopCh` closes (app shutdown), the watcher also exits.
```go
dataCh := make(chan string)
w := tui.NewChannelWatcher(dataCh, func(s string) {
messages.Update(func(list []string) []string {
return append(list, s)
})
})
```
### Watch
```go
func Watch[T any](ch <-chan T, handler func(T)) Watcher
```
A convenience wrapper around `NewChannelWatcher`. Returns the `Watcher` interface directly, which is what `Watchers()` expects.
```go
func (f *feed) Watchers() []tui.Watcher {
return []tui.Watcher{
tui.Watch(f.dataCh, func(item DataItem) {
f.items.Update(func(list []DataItem) []DataItem {
return append(list, item)
})
}),
}
}
```
Use `NewChannelWatcher` when you need the concrete `*ChannelWatcher[T]` type; use `Watch` when you just need a `Watcher` to return from `Watchers()`.
### Start
```go
func (w *ChannelWatcher[T]) Start(eventQueue chan<- func(), stopCh <-chan struct{})
```
Launches the goroutine that reads from the channel. Called automatically by the framework. The goroutine exits when either the channel closes or `stopCh` is closed.
## OnChange
```go
func OnChange[T any](state *State[T], handler func(T)) Watcher
```
Creates a watcher that calls `handler` when a `State[T]` value changes. The handler also fires once at startup with the current value.
Unlike `OnTimer` and `Watch`, this watcher doesn't spawn a goroutine for its main work. It uses `State.Bind` internally, so the handler runs synchronously during `State.Set()`. A small goroutine waits for the stop signal and removes the binding on shutdown.
```go
func (w *myApp) Watchers() []tui.Watcher {
return []tui.Watcher{
tui.OnChange(w.selectedTab, func(tab string) {
w.contentArea.ScrollTo(0)
}),
}
}
```
Use `OnChange` for side effects that should happen in response to state changes but don't belong in `Render()`: scrolling, logging, triggering secondary state updates, or kicking off background work via channels.
### Start
```go
func (w *stateWatcher[T]) Start(eventQueue chan<- func(), stopCh <-chan struct{})
```
Called automatically by the framework. Fires the handler once with the current state value, binds to future changes, and launches a goroutine that waits for `stopCh` to close before unbinding.
## WatcherProvider Interface
```go
type WatcherProvider interface {
Watchers() []Watcher
}
```
Implement this on a struct component to attach watchers to its lifecycle. The framework calls `Watchers()` after the component mounts and starts each returned watcher.
When the component unmounts, the framework closes the stop channel, which signals all watchers to exit.
```go
type dashboard struct {
elapsed *tui.State[int]
messages *tui.State[[]string]
dataCh <-chan string
}
func Dashboard(dataCh <-chan string) *dashboard {
return &dashboard{
elapsed: tui.NewState(0),
messages: tui.NewState([]string{}),
dataCh: dataCh,
}
}
func (d *dashboard) Watchers() []tui.Watcher {
return []tui.Watcher{
tui.OnTimer(time.Second, func() {
d.elapsed.Update(func(v int) int { return v + 1 })
}),
tui.Watch(d.dataCh, func(msg string) {
d.messages.Update(func(list []string) []string {
return append(list, msg)
})
}),
}
}
```
## Element-Level Watchers
Watchers can also be attached directly to elements, outside the component model.
### AddWatcher
```go
func (e *Element) AddWatcher(w Watcher)
```
Attaches a watcher to a specific element. The watcher starts when the element tree is set as the app root.
### Watchers
```go
func (e *Element) Watchers() []Watcher
```
Returns all watchers attached to the element.
### WalkWatchers
```go
func (e *Element) WalkWatchers(fn func(Watcher))
```
Recursively walks the element tree and calls `fn` for each attached watcher. Skips hidden elements and their subtrees. The framework uses this during `applyRoot` to discover and start all watchers.
## Lifecycle
Watchers follow this lifecycle:
1. Watchers are created in `Watchers()` or attached via `AddWatcher`.
2. The framework calls `Start(eventQueue, stopCh)` after the component mounts or the root is set. A goroutine begins running.
3. The goroutine loops, sending handler functions to the event queue.
4. When the component unmounts, the root changes, or the app stops, the framework closes `stopCh`. The goroutine detects the closed channel and exits.
Each time the root changes (via `SetRoot`, `SetRootView`, or `SetRootComponent`), the previous stop channel is closed and a new one is created. This ensures old watchers don't leak.
## Thread Safety
Watcher handlers run on the main event loop. This makes them safe for state mutation:
- Call `state.Set()` and `state.Update()` freely inside handlers.
- Access element properties without locks.
- Emit events via `Events[T].Emit()`.
Note: `OnChange` handlers run synchronously during `State.Set()` rather than being queued through the event loop. Since `Set()` must be called from the main loop, the same safety guarantees apply.
If you have a background goroutine that is *not* a watcher, use `app.QueueUpdate` to safely run code on the event loop:
```go
go func() {
result := expensiveComputation()
app.QueueUpdate(func() {
data.Set(result)
})
}()
```
## See Also
- [State Reference](state.md) — reactive state that watcher handlers typically modify
- [App Reference](app.md) — app lifecycle, `QueueUpdate`, component mounting
- [Events Reference](events.md) — keyboard and mouse event handling
|