Go
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Functions and Methods
-
Section 4: Concurrency
-
Section 5: Packages and Tooling
-
Section 6: More Standard Library
-
Section 7: Building Services
-
Section 8: Advanced Go
-
Section 9: Go in the Cloud-Native Ecosystem
-
Section 10: Data Structures and Algorithms in Go
-
Section 11: Testing and Deployment
-
Section 12: Practical Projects
-
Section 13: More Standard Library Practice
-
Section 14: More Practice Projects
-
Section 15: Design Patterns in Go
-
Section 16: Interview Practice
-
Section 17: Package fmt In Depth
-
Section 18: Package strings and strconv
-
Section 19: Package os and io
-
Section 20: Package time
-
Section 21: Package sort and container
-
Section 22: Package encoding
-
Section 23: Package net/http In Depth
-
Section 24: Package context
-
Section 25: Package regexp and bytes
-
Section 26: Package errors In Depth
-
Section 27: Package crypto and hash
-
Section 28: Package flag and log
-
Section 29: Package sync In Depth
-
Section 30: More Practice Exercises
-
Section 31: Go Modules and Workspaces In Depth
-
Section 32: Generics Deep Dive (Go 1.18+)
-
Section 33: Testing Package In Depth
-
Section 34: More Interview and Whiteboard Practice
-
Section 35: Package math and unicode
-
Section 36: Package path and filepath
-
Section 37: Package database/sql
-
Section 38: Package text/template and html/template
-
Section 39: Package archive and compress
-
Section 40: Lower-Level net Package
-
Section 41: Package runtime and reflect
-
Section 42: Package embed and io/fs
-
Section 43: Go Assembly and CGO Basics
-
Section 44: Building CLIs and TUIs
-
Section 45: Go Performance Tuning
-
Section 46: More Real-World Projects
-
Section 47: Go in Production
-
Section 48: Go Design Patterns
-
Section 49: Go Interfaces Deep Dive
-
Section 50: Final Practice and Review
215: Building Terminal UIs with Bubble Tea
If you've ever tried to build a terminal tool using basic fmt.Println calls, you know the pain: the moment you want to move the cursor, clear a line, or handle real-time keyboard input, you're suddenly diving into ANSI escape codes and raw terminal modes. It's a nightmare. That's why I use Bubble Tea. It brings the Elm Architecture (Model-Update-View) to Go, which basically means your UI becomes a predictable state machine rather than a tangled mess of print statements.
How do I actually structure my app using the Model-Update-View pattern?
Think of it as a loop. Your Model is the "source of truth" (your state), the Update function is where the logic lives, and the View is just a function that turns that state into a string. You never manually "print" to the screen; you just return a string from the View, and Bubble Tea handles the diffing and rendering.
Let's say we're building a simple Project Task Tracker. Here is how I'd set up the basic skeleton:
package main
import (
"fmt"
tea "github.com/charmbracelet/bubbletea"
)
// The Model holds the state of your application
type model struct {
tasks []string
cursor int
}
func initialModel() model {
return model{
tasks: []string{"Fix race condition", "Update README", "Refactor auth logic"},
cursor: 0,
}
}
// Init is for things that happen on startup (like starting a timer)
func (m model) Init() tea.Cmd {
return nil
}
// View renders the current state of the model as a string
func (m model) View() string {
s := "Project Tasks:\n\n"
for i, task := range m.tasks {
cursor := " "
if m.cursor == i {
cursor = ">" // Highlight the current selection
}
s += fmt.Sprintf("%s %s\n", cursor, task)
}
s += "\n(q to quit, j/k to move)"
return s
}
How do I handle keyboard input without a giant mess of if/else blocks?
You do this inside the Update method. Every time a user presses a key, Bubble Tea sends a tea.Msg to this function. The trick is to use a type switch. I usually handle the "global" keys (like quitting) first, then move into the specific logic for the current state.
I've found that if you don't keep your Update function clean, it becomes a monolith very quickly. Break your logic into small helper methods if it gets too long.
func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
switch msg := msg.(type) {
case tea.KeyMsg:
switch msg.String() {
case "q", "ctrl+c":
return m, tea.Quit
case "k": // Move cursor up
if m.cursor > 0 {
m.cursor--
}
case "j": // Move cursor down
if m.cursor < len(m.tasks)-1 {
m.cursor++
}
}
}
return m, nil
}
What's the deal with Cmds? Can't I just call a function inside Update?
This is the part that trips most people up. Never put blocking code (like an API call, a heavy database query, or time.Sleep) inside your Update function. If you do, the entire UI will freeze until that function returns, and your user will think the app crashed.
Instead, you return a tea.Cmd. A Command is essentially a function that runs in the background and, when it finishes, returns a tea.Msg. Bubble Tea then feeds that message back into your Update function. It's an asynchronous loop.
For example, if you wanted to "save" a task to a file, you'd return a Command that does the I/O and then returns a saveSuccessMsg. You then handle that saveSuccessMsg in your switch statement to update the UI with a "Saved!" notification. It feels like a bit more boilerplate at first, but it's the only way to keep a terminal UI feeling snappy.
How do I make the UI actually look professional?
Bubble Tea is for the logic; for the styling, you want to use Lip Gloss (another library from the same creators). Lip Gloss lets you define styles—colors, borders, padding—and apply them to your strings. I always define my styles as global variables or part of the model so I'm not recreating them on every render cycle.
Instead of just returning a plain string in View(), you'd do something like: return style.Render("Hello World"). When you combine Bubble Tea's state management with Lip Gloss's layout capabilities, you can build interfaces that honestly don't look like they're running in a terminal.
📋 Practical Task
Exercise: Build a Keyboard-Controlled Task Priority Sorter
Create a Bubble Tea application that manages a list of tasks. The goal is to implement a "reorder" feature using the keyboard.
- State: Start with a slice of 3-5 strings representing tasks.
- Navigation: Use 'j' and 'k' to move a cursor up and down the list.
- Logic: Implement the 'u' key to move the currently selected task up one position in the slice, and the 'd' key to move it down one position.
- Visuals: Ensure the current task is marked with a pointer (e.g.,
→) and that the list updates immediately when a task is moved. - Exit: Allow the user to quit using 'q' or 'ctrl+c'.
There are no comments for now.