Course outline

01 · Getting Started6/6

02 · Variables, Types & Control Flow6/6

03 · Functions & Composite Types6/6

04 · Methods, Interfaces & Errors6/6

05 · Packages, Modules & Concurrency Intro6/6

06 · Your First Real Program6/6

07 · Testing & Debugging in Go6/6

08 · Capstone — Ship a Real Tool7/7

09 · Generics6/6

10 · Concurrency in Practice6/6

11 · Language Depth II6/6

12 · Standard Library Toolkit6/6

13 · Building Web Services6/6

14 · Working with Databases6/6

15 · Advanced Runtime & Tooling6/6

16 · Building a Terminal Dashboard with Bubble Tea5/5

17 · Closing the Loop2/2

Stage 1 · Code

Building a Terminal Dashboard with Bubble Tea

Wiring the Bubble Tea Model

Take the Model/Update/View pattern from theory to a running dashboard: a struct that holds state, a function that reacts to keys and time, and a function that renders it all with the styles from the last lesson.

11 min readThe Complete Go EngineerCode

The Model Struct

Everything burnrate's dashboard knows at any moment lives in one struct. Not global variables, not package-level mutable state — one value that gets passed into Update and out again, updated, on every single event.

Gointernal/tui/model.go-—-the-model-type.go

49 linesLn 1, Col 1Go

`progress.Model` comes from Bubbles, Charm's library of ready-made Bubble Tea components — a progress gauge, in this case, so burnrate doesn't need to hand-draw a percentage bar out of characters. Everything else in the struct is plain data: the budget, the windows to check, and where traffic samples come from.

Init and a Ticking Clock

Init runs exactly once, before the very first draw, and its job is to return whatever command should kick things off. For a live dashboard, that command is "start ticking once a second." For a static snapshot, there is nothing to kick off — it draws once and waits for the user to quit.

Gointernal/tui/model.go-—-init-and-the-tick-command.go

16 linesLn 1, Col 1Go

`tea.Cmd` is just a function that does some work and returns a `tea.Msg` describing what happened. `tea.Tick` is a helper Bubble Tea provides for the extremely common "do something after a delay" case — here, it fires a `tickMsg` once a second. Commands are how Bubble Tea does anything asynchronous without you writing raw goroutine-and-channel code by hand.

Update: Reacting to Events

Every event Bubble Tea's runtime knows about — a key press, a terminal resize, or your own tickMsg — arrives at Update as a tea.Msg. A type switch decides what kind of message it is and what should happen next.

Gointernal/tui/model.go-—-update.go

29 linesLn 1, Col 1Go

Three cases, three responsibilities: key presses toggle quit/pause, a window-resize message records the new size for View to use, and a tick advances the simulated clock and re-queues the next tick. Notice that `tickEvery()` is called again inside the `tickMsg` case — that is what keeps the clock running: each tick schedules the next one.

Why Update returns a copy, not a pointer

Model methods use a value receiver, and Update returns a (possibly modified) copy rather than mutating through a pointer. This mirrors the immutable-update style Elm popularized: every step of the program is an explicit, traceable "old state in, new state out" transformation, with no hidden mutation to chase down when something behaves unexpectedly.

View: Rendering the Frame

View takes no arguments beyond the model itself and returns one plain string — the entire screen, re-rendered from scratch on every draw. Bubble Tea's runtime is responsible for turning that string into an efficient terminal redraw; your only job is to describe what the screen should currently look like.

Gointernal/tui/model.go-—-view.go

45 linesLn 1, Col 1Go

Every style from the previous lesson gets used exactly once, on exactly the piece of text it belongs to: `titleStyle` on the header, `badgeStyle` on each window's status pill, `frameStyle` wrapped around the entire finished string last, so the whole dashboard gets one consistent rounded border. And notice the last line before the frame closes: burnrate credits Charm directly, in the running program itself, not just in a README.

Wiring It Into main.go

With a Model that implements Init, Update, and View, starting the whole program is two lines: build a tea.Program from your model, and call .Run().

Gocmd/burnrate/main.go-—-starting-the-program.go

5 linesLn 1, Col 1Go

`tea.NewProgram` wraps your model in Bubble Tea's runtime, which owns the terminal for as long as the program runs — capturing key presses, delivering tick messages, and redrawing the screen from whatever `View` returns. `p.Run()` blocks until the model returns `tea.Quit`, which happens the moment the user presses "q".

Run it now

At this point go run ./cmd/burnrate demo already produces a live, ticking dashboard with real burn-rate math behind it. The next lesson adds the two ways burnrate gets its numbers — a simulated demo feed and a real JSON snapshot — and wraps up with the README and credit that go with a finished, shared tool.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.