Build Tui View
Build consistent Terminal User Interface views for Hatchet CLI using bubbletea
✨ The solution you've been looking for
Provides instructions for building Hatchet TUI views in the Hatchet CLI.
See It In Action
Interactive preview & real-world examples
AI Conversation Simulator
See how users interact with this skill
User Prompt
I need to create a new TUI view for displaying workflow runs with columns for name, status, created date, and duration. It should use the Hatchet theme and follow the standard layout.
Skill Processing
Analyzing request...
Agent Response
Complete TUI view implementation with header, table, footer, keyboard controls, and API integration following established patterns
Quick Start (3 Steps)
Get up and running in minutes
Install
claude-code skill install build-tui-view
claude-code skill install build-tui-viewConfig
First Trigger
@build-tui-view helpCommands
| Command | Description | Required Args |
|---|---|---|
| @build-tui-view create-new-tui-view-for-data-listing | Build a table-based view that displays API data with proper navigation and controls | None |
| @build-tui-view add-detail-view-with-navigation | Implement drill-down detail views that connect to existing list views | None |
| @build-tui-view integrate-forms-and-filtering | Add interactive forms for filtering and configuration within TUI views | None |
Typical Use Cases
Create new TUI view for data listing
Build a table-based view that displays API data with proper navigation and controls
Add detail view with navigation
Implement drill-down detail views that connect to existing list views
Integrate forms and filtering
Add interactive forms for filtering and configuration within TUI views
Overview
📝 SELF-UPDATING DOCUMENT: This skill automatically updates itself when inaccuracies are discovered or new patterns are learned. Always verify information against the actual codebase and update this file when needed.
Overview
This skill provides instructions for creating and maintaining Terminal User Interface (TUI) views in the Hatchet CLI using bubbletea and lipgloss. The TUI system uses a modular view architecture where individual views are isolated in separate files within the views/ directory.
IMPORTANT: Always start by finding the corresponding view in the frontend application to understand the structure, columns, and API calls.
Self-Updating Skill Instructions
CRITICAL - READ FIRST: This skill document is designed to be continuously improved and kept accurate.
When to Update This Skill
You MUST update this skill file in the following situations:
Discovering Inaccuracies
- When you find incorrect file paths or directory structures
- When code examples don’t compile or don’t match actual implementations
- When API signatures have changed
- When referenced files don’t exist at specified locations
Learning New Patterns
- When implementing a new view and discovering better approaches
- When the user teaches you new conventions or patterns
- When you find reusable patterns that should be documented
- When you discover common pitfalls that should be warned about
Finding Missing Information
- When you need information that isn’t documented here
- When new components or utilities are added to the codebase
- When new bubbletea/lipgloss patterns are adopted
User Corrections
- When the user corrects any information in this document
- When the user provides updated approaches or conventions
- When the user points out outdated information
How to Update This Skill
When updating this skill:
- Verify Before Adding: Always verify paths, code, and API signatures against the actual codebase before adding to this document
- Use Read/Glob/Grep: Check the actual files to ensure accuracy
- Test Code Examples: Ensure code examples compile and follow current patterns
- Be Specific: Include exact file paths, function signatures, and working code examples
- Update Immediately: Make updates as soon as inaccuracies are discovered, not at the end of a session
- Preserve Structure: Maintain the existing document structure and formatting
- Add Context: When adding new sections, explain why the pattern is recommended
Verification Checklist
Before using information from this skill, verify:
- File paths exist and are correct
- Code examples match current implementations
- API signatures match the generated REST client
- Reusable components are correctly referenced
- Directory structures are accurate
Self-Correction Process
If you discover an inaccuracy while working:
- Immediately note the issue
- Verify the correct information by reading the actual files
- Update this skill document with the correction
- Continue with the user’s task using the corrected information
Remember: This skill should be a living document that grows more accurate and comprehensive with each use.
Project Context
- Framework: bubbletea (TUI framework)
- Styling: lipgloss (style definitions)
- TUI Command Location:
cmd/hatchet-cli/cli/tui.go - Views Location:
cmd/hatchet-cli/cli/tui/directory - Theme: Pre-defined Hatchet theme in
cmd/hatchet-cli/cli/internal/styles/styles.go - Frontend Reference:
frontend/app/src/pages/main/v1/directory
Finding Frontend Prior Art
CRITICAL FIRST STEP: Before implementing any TUI view, locate the corresponding frontend view to understand:
- Column structure and names
- API endpoints and query parameters
- Data types and fields used
- Filtering and sorting logic
Process for Finding Frontend Reference:
Locate the Frontend View
1# Navigate to frontend pages 2cd frontend/app/src/pages/main/v1/ 3 4# Find views related to your feature (e.g., workflow-runs, tasks, events) 5ls -laStudy the Column Definitions
- Look for files like
{feature}-columns.tsx - Note the column keys, titles, and accessors
- Example:
frontend/app/src/pages/main/v1/workflow-runs-v1/components/v1/task-runs-columns.tsx
1export const TaskRunColumn = { 2 taskName: "Task Name", 3 status: "Status", 4 workflow: "Workflow", 5 createdAt: "Created At", 6 startedAt: "Started At", 7 duration: "Duration", 8};- Look for files like
Identify the Data Hook
- Look for
use-{feature}.tsxfiles in thehooks/directory - These contain the API query logic
- Example:
frontend/app/src/pages/main/v1/workflow-runs-v1/hooks/use-runs.tsx
- Look for
Find the API Query
- Check
frontend/app/src/lib/api/queries.tsfor the query definition - Note the endpoint name and parameters
- Example:
1v1WorkflowRuns: { 2 list: (tenant: string, query: V2ListWorkflowRunsQuery) => ({ 3 queryKey: ['v1:workflow-run:list', tenant, query], 4 queryFn: async () => (await api.v1WorkflowRunList(tenant, query)).data, 5 }), 6}- Check
Map to Go REST Client
- The frontend
api.v1WorkflowRunList()maps to Go’sclient.API().V1WorkflowRunListWithResponse() - Frontend query parameters map to Go struct parameters
- Example mapping:
1// Frontend 2api.v1WorkflowRunList(tenantId, { 3 offset: 0, 4 limit: 100, 5 since: createdAfter, 6 only_tasks: true, 7}) 8 9// Go equivalent 10client.API().V1WorkflowRunListWithResponse( 11 ctx, 12 client.TenantId(), 13 &rest.V1WorkflowRunListParams{ 14 Offset: int64Ptr(0), 15 Limit: int64Ptr(100), 16 Since: &since, 17 OnlyTasks: true, 18 }, 19)- The frontend
Example: Implementing Tasks View from Frontend Reference
Frontend Structure:
frontend/app/src/pages/main/v1/workflow-runs-v1/- Columns:
task-runs-columns.tsx - Hook:
use-runs.tsx - Table:
runs-table.tsx
- Columns:
Extract Column Names:
1taskName, status, workflow, createdAt, startedAt, duration;Identify API Call:
1queries.v1WorkflowRuns.list(tenantId, { 2 offset, 3 limit, 4 statuses, 5 workflow_ids, 6 since, 7 until, 8 only_tasks: true, 9});Implement in TUI:
1// Create matching columns 2columns := []table.Column{ 3 {Title: "Task Name", Width: 30}, 4 {Title: "Status", Width: 12}, 5 {Title: "Workflow", Width: 25}, 6 {Title: "Created At", Width: 16}, 7 {Title: "Started At", Width: 16}, 8 {Title: "Duration", Width: 12}, 9} 10 11// Call matching API endpoint 12response, err := client.API().V1WorkflowRunListWithResponse( 13 ctx, 14 client.TenantId(), 15 &rest.V1WorkflowRunListParams{ 16 Offset: int64Ptr(0), 17 Limit: int64Ptr(100), 18 Since: &since, 19 OnlyTasks: true, 20 }, 21)
Reusable Components (CRITICAL - READ FIRST)
IMPORTANT: All TUI views MUST use the standardized reusable components defined in view.go to ensure consistency across the application. DO NOT copy-paste header/footer styling code.
Header Component
CRITICAL: ALL headers throughout the TUI use the magenta highlight color (styles.HighlightColor) for the title to provide consistent visual emphasis across all views (primary views, detail views, modals, etc.).
For Detail Views and Modals
Always use RenderHeader() for detail views, modals, and secondary screens:
1header := RenderHeader("Workflow Details", v.Ctx.ProfileName, v.Width)
2header := RenderHeader("Task Details", v.Ctx.ProfileName, v.Width)
3header := RenderHeader("Filter Tasks", v.Ctx.ProfileName, v.Width)
For Primary Views
Use RenderHeaderWithViewIndicator() for primary/list views:
1// For primary list views - shows just the view name, no repetitive "Hatchet Workflows [Workflows]"
2header := RenderHeaderWithViewIndicator("Runs", v.Ctx.ProfileName, v.Width)
3header := RenderHeaderWithViewIndicator("Workflows", v.Ctx.ProfileName, v.Width)
This function renders just the view name (e.g., “Runs” or “Workflows”) in the highlight color, keeping it simple and non-repetitive.
Features of both header functions:
- Title rendered in magenta highlight color (
styles.HighlightColor) - consistent across ALL views - Includes the logo (text-based: “HATCHET TUI”) on the right
- Shows profile name
- Bordered bottom edge
- Responsive to terminal width
❌ NEVER do this:
1// Bad: Copy-pasting header styles
2headerStyle := lipgloss.NewStyle().
3 Bold(true).
4 Foreground(styles.AccentColor).
5 BorderStyle(lipgloss.NormalBorder()).
6 // ... more styling
7header := headerStyle.Render(fmt.Sprintf("My View - Profile: %s", profile))
8
9// Bad: Calling RenderHeaderWithLogo directly (bypasses highlight color)
10header := RenderHeaderWithLogo(fmt.Sprintf("My View - Profile: %s", profile), v.Width)
✅ ALWAYS do this:
1// Good: Use the reusable component for detail views
2header := RenderHeader("Task Details", v.Ctx.ProfileName, v.Width)
3
4// Good: Use the view indicator variant for primary views
5header := RenderHeaderWithViewIndicator("Runs", v.Ctx.ProfileName, v.Width)
Instructions Component
Use RenderInstructions() to display contextual help text:
1instructions := RenderInstructions(
2 "Your instructions here • Use bullets to separate items",
3 v.Width,
4)
Features:
- Muted color styling for reduced visual noise
- Automatically handles width constraints
- Consistent padding
- Uses bullet separators (•)
Footer Component
Always use RenderFooter() for navigation/control hints:
1footer := RenderFooter([]string{
2 "↑/↓: Navigate",
3 "Enter: Select",
4 "Esc: Cancel",
5 "q: Quit",
6}, v.Width)
Features:
- Consistent styling with top border
- Automatically joins control items with bullets (•)
- Muted color for non-intrusive display
- Responsive to terminal width
Standard View Structure
Every view should follow this consistent structure:
1func (v *YourView) View() string {
2 var b strings.Builder
3
4 // 1. Header (always) - USE REUSABLE COMPONENT
5 header := RenderHeader("View Title", v.Ctx.ProfileName, v.Width)
6 b.WriteString(header)
7 b.WriteString("\n\n")
8
9 // 2. Instructions (when helpful) - USE REUSABLE COMPONENT
10 instructions := RenderInstructions("Your instructions", v.Width)
11 b.WriteString(instructions)
12 b.WriteString("\n\n")
13
14 // 3. Main content
15 // ... your view-specific content ...
16
17 // 4. Footer (always) - USE REUSABLE COMPONENT
18 footer := RenderFooter([]string{
19 "control1: Action1",
20 "control2: Action2",
21 }, v.Width)
22 b.WriteString(footer)
23
24 return b.String()
25}
Architecture
Root TUI Model (tui.go)
The root TUI command is responsible for:
- Profile selection and validation
- Initializing the Hatchet client
- Creating the view context
- Managing the current view
- Delegating updates to views
View System (views/ directory)
Each view is a separate file that implements the View interface:
view.go- Base view interface, context, and reusable components{viewname}.go- Individual view implementations (e.g.,tasks.go)
Core Principles
1. File Structure
TUI Command File
- File:
cmd/hatchet-cli/cli/tui.go - Purpose: Command setup, profile selection, client initialization, view management
View Files
- Location:
cmd/hatchet-cli/cli/tui/ - Files:
view.go- View interface and base types{viewname}.go- Individual view implementations
2. View Interface
All views must implement this interface (defined in views/view.go):
1package views
2
3import (
4 tea "github.com/charmbracelet/bubbletea"
5 "github.com/hatchet-dev/hatchet/pkg/client"
6)
7
8// ViewContext contains the shared context passed to all views
9type ViewContext struct {
10 // Profile name for display
11 ProfileName string
12
13 // Hatchet client for API calls
14 Client client.Client
15
16 // Terminal dimensions
17 Width int
18 Height int
19}
20
21// View represents a TUI view component
22type View interface {
23 // Init initializes the view and returns any initial commands
24 Init() tea.Cmd
25
26 // Update handles messages and updates the view state
27 Update(msg tea.Msg) (View, tea.Cmd)
28
29 // View renders the view to a string
30 View() string
31
32 // SetSize updates the view dimensions
33 SetSize(width, height int)
34}
3. Base Model Pattern
Use BaseModel for common view fields:
1// BaseModel contains common fields for all views
2type BaseModel struct {
3 Ctx ViewContext
4 Width int
5 Height int
6 Err error
7}
8
9// Your view embeds BaseModel
10type YourView struct {
11 BaseModel
12 // Your view-specific fields
13 table table.Model
14 items []YourDataType
15}
4. Creating a New View
Step 1: Create View File
Create cmd/hatchet-cli/cli/tui/{viewname}.go:
1package views
2
3import (
4 tea "github.com/charmbracelet/bubbletea"
5 "github.com/hatchet-dev/hatchet/cmd/hatchet-cli/cli/internal/styles"
6 "github.com/hatchet-dev/hatchet/pkg/client/rest"
7)
8
9type YourView struct {
10 BaseModel
11 // View-specific fields
12}
13
14// NewYourView creates a new instance of your view
15func NewYourView(ctx ViewContext) *YourView {
16 v := &YourView{
17 BaseModel: BaseModel{
18 Ctx: ctx,
19 },
20 }
21
22 // Initialize view components
23
24 return v
25}
26
27func (v *YourView) Init() tea.Cmd {
28 return nil
29}
30
31func (v *YourView) Update(msg tea.Msg) (View, tea.Cmd) {
32 var cmd tea.Cmd
33
34 switch msg := msg.(type) {
35 case tea.WindowSizeMsg:
36 v.SetSize(msg.Width, msg.Height)
37 return v, nil
38
39 case tea.KeyMsg:
40 switch msg.String() {
41 case "r":
42 // Refresh logic
43 return v, nil
44 }
45 }
46
47 // Update sub-components
48 return v, cmd
49}
50
51func (v *YourView) View() string {
52 if v.Width == 0 {
53 return "Initializing..."
54 }
55
56 // Build your view
57 return "Your view content"
58}
59
60func (v *YourView) SetSize(width, height int) {
61 v.BaseModel.SetSize(width, height)
62 // Update view-specific components
63}
Step 2: Use View in TUI
The root TUI model manages views:
1// In tui.go
2func newTUIModel(profileName string, hatchetClient client.Client) tuiModel {
3 ctx := views.ViewContext{
4 ProfileName: profileName,
5 Client: hatchetClient,
6 }
7
8 // Initialize with your view
9 currentView := views.NewYourView(ctx)
10
11 return tuiModel{
12 currentView: currentView,
13 }
14}
5. Client Initialization Pattern
Always initialize the Hatchet client in tui.go:
1import (
2 "github.com/rs/zerolog"
3 "github.com/hatchet-dev/hatchet/pkg/client"
4)
5
6// In the cobra command Run function
7profile, err := cli.GetProfile(selectedProfile)
8if err != nil {
9 cli.Logger.Fatalf("could not get profile '%s': %v", selectedProfile, err)
10}
11
12// Initialize Hatchet client
13nopLogger := zerolog.Nop()
14hatchetClient, err := client.New(
15 client.WithToken(profile.Token),
16 client.WithLogger(&nopLogger),
17)
18if err != nil {
19 cli.Logger.Fatalf("could not create Hatchet client: %v", err)
20}
6. Accessing the Client in Views
The Hatchet client is available through the view context:
1func (v *YourView) fetchData() tea.Cmd {
2 return func() tea.Msg {
3 // Access the client
4 client := v.Ctx.Client
5
6 // Make API calls
7 // response, err := client.API().SomeEndpoint(...)
8
9 return yourDataMsg{
10 data: data,
11 err: err,
12 }
13 }
14}
7. Hatchet Theme Integration
CRITICAL: NEVER hardcode colors or styles in view files. Always use the pre-defined Hatchet theme colors and utilities from cmd/hatchet-cli/cli/internal/styles.
Available Theme Colors
1import "github.com/hatchet-dev/hatchet/cmd/hatchet-cli/cli/internal/styles"
2
3// Primary theme colors:
4// - styles.AccentColor
5// - styles.PrimaryColor
6// - styles.SuccessColor
7// - styles.HighlightColor
8// - styles.MutedColor
9// - styles.Blue, styles.Cyan, styles.Magenta
10
11// Status colors (matching frontend badge variants):
12// - styles.StatusSuccessColor / styles.StatusSuccessBg
13// - styles.StatusFailedColor / styles.StatusFailedBg
14// - styles.StatusInProgressColor / styles.StatusInProgressBg
15// - styles.StatusQueuedColor / styles.StatusQueuedBg
16// - styles.StatusCancelledColor / styles.StatusCancelledBg
17// - styles.ErrorColor
18
19// Available styles:
20// - styles.H1, styles.H2
21// - styles.Bold, styles.Italic
22// - styles.Primary, styles.Accent, styles.Success
23// - styles.Code
24// - styles.Box, styles.InfoBox, styles.SuccessBox
Status Rendering
Per-Cell Coloring in Tables: Use the custom TableWithStyleFunc wrapper to enable per-cell styling.
For status rendering in tables:
1// Create table with StyleFunc support
2t := NewTableWithStyleFunc(
3 table.WithColumns(columns),
4 table.WithFocused(true),
5 table.WithHeight(20),
6)
7
8// Set StyleFunc for per-cell styling
9t.SetStyleFunc(func(row, col int) lipgloss.Style {
10 // Column 1 is the status column
11 if col == 1 && row < len(v.tasks) {
12 statusStyle := styles.GetV1TaskStatusStyle(v.tasks[row].Status)
13 return lipgloss.NewStyle().Foreground(statusStyle.Foreground)
14 }
15 return lipgloss.NewStyle()
16})
17
18// In updateTableRows, use plain text (StyleFunc applies colors)
19statusStyle := styles.GetV1TaskStatusStyle(task.Status)
20status := statusStyle.Text // "Succeeded", "Failed", etc.
For non-table contexts (headers, footers, standalone text):
1// Render V1TaskStatus with proper colors
2status := styles.RenderV1TaskStatus(task.Status)
3
4// Render error messages
5errorMsg := styles.RenderError(fmt.Sprintf("Error: %v", err))
Why custom TableWithStyleFunc?
- Standard bubbles table doesn’t support per-cell or per-column styling
TableWithStyleFuncwraps bubbles table and adds StyleFunc support- StyleFunc allows dynamic cell styling based on row/column index
- Located in
cmd/hatchet-cli/cli/tui/table_custom.go - Maintains bubbles table interactivity (cursor, selection, keyboard nav)
Table Styling
1s := table.DefaultStyles()
2s.Header = s.Header.
3 BorderStyle(lipgloss.NormalBorder()).
4 BorderForeground(styles.AccentColor).
5 BorderBottom(true).
6 Bold(true).
7 Foreground(styles.AccentColor)
8s.Selected = s.Selected.
9 Foreground(lipgloss.AdaptiveColor{Light: "#ffffff", Dark: "#0A1029"}).
10 Background(styles.Blue).
11 Bold(true)
Note: Use lipgloss.AdaptiveColor even for basic colors like white/black to support light/dark terminals.
Adding New Status Colors
If you need to add new status colors:
- Add the color constants to
cmd/hatchet-cli/cli/internal/styles/styles.go - Create or update the utility function in
cmd/hatchet-cli/cli/internal/styles/status.go - Reference the frontend badge variants in
frontend/app/src/components/v1/ui/badge.tsxfor color values - Use adaptive colors for light/dark terminal support
8. Standard Keyboard Controls
Use consistent key mappings across all views to provide a predictable user experience.
Global Controls (handled in tui.go)
qorctrl+c: Quit the TUI
View-Specific Controls
Implement these in individual views:
- Navigation:
↑/↓or arrow keys for list navigation - Selection:
Enterto select/confirm - Tab Navigation:
Tab/Shift+Tabfor form fields - Cancel:
Escto go back/cancel - Refresh:
rto manually refresh data - Filter:
fto open filter modal (where applicable) - Debug:
dto toggle debug view (see Debug Logging section) - Clear:
cto clear debug logs (when in debug view) - Tab Views:
1,2,3, etc. ortab/shift+tabfor switching tabs
Important: Always document keyboard controls in the footer using RenderFooter()
9. Layout Components
CRITICAL: Use the reusable components from view.go for headers, instructions, and footers. See “Reusable Components” section above.
Header
✅ Use the reusable component:
1header := RenderHeader("View Title", v.Ctx.ProfileName, v.Width)
❌ DO NOT manually create headers:
1// Bad: Don't do this
2headerStyle := lipgloss.NewStyle().
3 Bold(true).
4 Foreground(styles.AccentColor).
5 // ... (this violates DRY principle)
Footer
✅ Use the reusable component:
1footer := RenderFooter([]string{
2 "↑/↓: Navigate",
3 "r: Refresh",
4 "q: Quit",
5}, v.Width)
❌ DO NOT manually create footers:
1// Bad: Don't do this
2footerStyle := lipgloss.NewStyle().
3 Foreground(styles.MutedColor).
4 // ... (this violates DRY principle)
Instructions
✅ Use the reusable component:
1instructions := RenderInstructions("Your helpful instructions here", v.Width)
Stats Bar
Custom stats bars are fine for view-specific metrics:
1statsStyle := lipgloss.NewStyle().
2 Foreground(styles.MutedColor).
3 Padding(0, 1)
4
5stats := statsStyle.Render(fmt.Sprintf(
6 "Total: %d | Status1: %d | Status2: %d",
7 total, status1Count, status2Count,
8))
10. Data Integration
REST API Types
Use generated REST types from:
1import "github.com/hatchet-dev/hatchet/pkg/client/rest"
Common types:
rest.V1TaskSummaryrest.V1TaskSummaryListrest.V1WorkflowRunrest.V1WorkflowRunDetailsrest.Workerrest.WorkerRuntimeInforest.Workflowrest.APIResourceMeta
Async Data Fetching Pattern
1// Define custom message types in your view file
2type yourDataMsg struct {
3 items []YourDataType
4 err error
5}
6
7// Create fetch command
8func (v *YourView) fetchData() tea.Cmd {
9 return func() tea.Msg {
10 // Use v.Ctx.Client to make API calls
11 // Return yourDataMsg
12 }
13}
14
15// Handle in Update
16case yourDataMsg:
17 v.loading = false
18 if msg.err != nil {
19 v.HandleError(msg.err)
20 } else {
21 v.items = msg.items
22 v.ClearError()
23 }
11. Modal Views
When creating modal overlays (like filter forms or confirmation dialogs):
- Still show the header with updated title using
RenderHeader() - Show instructions specific to the modal interaction using
RenderInstructions() - Show the modal content
- Show a footer with modal-specific controls using
RenderFooter()
Example Modal Structure:
1func (v *TasksView) renderFilterModal() string {
2 var b strings.Builder
3
4 // 1. Header - USE REUSABLE COMPONENT
5 header := RenderHeader("Filter Tasks", v.Ctx.ProfileName, v.Width)
6 b.WriteString(header)
7 b.WriteString("\n\n")
8
9 // 2. Instructions - USE REUSABLE COMPONENT
10 instructions := RenderInstructions("Configure filters and press Enter to apply", v.Width)
11 b.WriteString(instructions)
12 b.WriteString("\n\n")
13
14 // 3. Modal content (form, etc.)
15 b.WriteString(v.filterForm.View())
16 b.WriteString("\n")
17
18 // 4. Footer - USE REUSABLE COMPONENT
19 footer := RenderFooter([]string{"Enter: Apply", "Esc: Cancel"}, v.Width)
20 b.WriteString(footer)
21
22 return b.String()
23}
Important: Modals should maintain the same visual structure as regular views (header, instructions, content, footer) for consistency.
12. Form Integration
When using huh forms in views:
- Set the Hatchet theme:
.WithTheme(styles.HatchetTheme()) - Integrate forms directly into the main tea.Program (don’t run separate programs)
- Handle form completion by checking
form.State == huh.StateCompleted - Pass ALL messages to the form when it’s active (not just key messages)
Example:
1import "github.com/charmbracelet/huh"
2
3// In Update()
4if v.showingFilter && v.filterForm != nil {
5 // Pass ALL messages to form when active
6 form, cmd := v.filterForm.Update(msg)
7 v.filterForm = form.(*huh.Form)
8
9 // Check if form completed
10 if v.filterForm.State == huh.StateCompleted {
11 v.showingFilter = false
12 // Process form values
13 }
14
15 return v, cmd
16}
13. Table Component
Using github.com/charmbracelet/bubbles/table:
1import "github.com/charmbracelet/bubbles/table"
2
3// Define columns
4columns := []table.Column{
5 {Title: "Column1", Width: 20},
6 {Title: "Column2", Width: 30},
7}
8
9// Create table
10t := table.New(
11 table.WithColumns(columns),
12 table.WithFocused(true),
13 table.WithHeight(20),
14)
15
16// Apply Hatchet styles
17s := table.DefaultStyles()
18s.Header = s.Header.
19 BorderStyle(lipgloss.NormalBorder()).
20 BorderForeground(styles.AccentColor).
21 BorderBottom(true).
22 Bold(true).
23 Foreground(styles.AccentColor)
24s.Selected = s.Selected.
25 Foreground(lipgloss.AdaptiveColor{Light: "#ffffff", Dark: "#0A1029"}).
26 Background(styles.Blue).
27 Bold(true)
28t.SetStyles(s)
29
30// Update rows
31rows := make([]table.Row, len(items))
32for i, item := range items {
33 rows[i] = table.Row{item.Field1, item.Field2}
34}
35t.SetRows(rows)
14. Table Height Calculations and Layout Optimization
CRITICAL: Proper table height calculation is essential for optimal use of terminal space. Different view types require different calculations based on the UI elements displayed above and below the table.
Standard Height Calculations by View Type
Primary List Views (e.g., runs_list, workflows):
- Calculation:
height - 12 - Accounts for: header (3 lines), stats bar (2 lines), spacing (2 lines), footer (2 lines), buffer (3 lines)
1func (v *RunsListView) Update(msg tea.Msg) (View, tea.Cmd) {
2 switch msg := msg.(type) {
3 case tea.WindowSizeMsg:
4 v.SetSize(msg.Width, msg.Height)
5 v.table.SetHeight(msg.Height - 12) // Primary view calculation
6 return v, nil
7 }
8 // ...
9}
10
11func (v *RunsListView) SetSize(width, height int) {
12 v.BaseModel.SetSize(width, height)
13 if height > 12 {
14 v.table.SetHeight(height - 12)
15 }
16}
Detail Views with Additional Info Sections (e.g., workflow_details with workflow info + runs table):
- Calculation:
height - 16(or adjust based on info section size) - Accounts for: header (3 lines), info section (4 lines), section header (2 lines), spacing (2 lines), footer (2 lines), buffer (3 lines)
1func (v *WorkflowDetailsView) Update(msg tea.Msg) (View, tea.Cmd) {
2 switch msg := msg.(type) {
3 case tea.WindowSizeMsg:
4 v.SetSize(msg.Width, msg.Height)
5 v.table.SetHeight(msg.Height - 16) // Detail view with extra info
6 return v, nil
7 }
8 // ...
9}
10
11func (v *WorkflowDetailsView) SetSize(width, height int) {
12 v.BaseModel.SetSize(width, height)
13 if height > 16 {
14 v.table.SetHeight(height - 16)
15 }
16}
Guidelines for Height Calculation
- Count Your UI Elements: List all elements that appear above and below the table
- Estimate Line Counts:
- Header: ~3 lines (with spacing)
- Stats bar: ~2 lines (with spacing)
- Section headers: ~2 lines each
- Info sections: ~3-5 lines depending on content
- Footer: ~2 lines (with spacing)
- Buffer: ~2-3 lines for safety
- Test at Different Sizes: Verify the table has adequate space at minimum terminal size (80x24)
- Iterate if Needed: If the table feels cramped, reduce the height offset by 2-4 lines
Common Mistake: Using the same height calculation for all views without accounting for additional UI elements.
❌ Wrong:
1// Detail view with extra info section but using primary view calculation
2v.table.SetHeight(msg.Height - 12) // Table will be too large, overlapping footer
✅ Correct:
1// Adjust calculation based on actual UI elements in the view
2v.table.SetHeight(msg.Height - 16) // Accounts for extra info section
15. Column Consistency Between Related Views
CRITICAL: When a detail view displays a list that’s conceptually similar to a primary list view (e.g., workflow details showing recent runs, same as the main runs list), the columns MUST match exactly to maintain consistency and user expectations.
Why Column Consistency Matters
- User Experience: Users expect the same information in the same format across views
- Cognitive Load: Consistent columns reduce mental overhead when switching contexts
- Visual Familiarity: Same column structure reinforces the relationship between views
Example: Runs List Columns
Primary View (runs_list.go):
1columns := []table.Column{
2 {Title: "Task Name", Width: 30},
3 {Title: "Status", Width: 12},
4 {Title: "Workflow", Width: 25},
5 {Title: "Created At", Width: 16},
6 {Title: "Started At", Width: 16},
7 {Title: "Duration", Width: 12},
8}
Detail View (workflow_details.go showing recent runs for a workflow):
1// MUST use the same columns as runs_list.go
2columns := []table.Column{
3 {Title: "Task Name", Width: 30},
4 {Title: "Status", Width: 12},
5 {Title: "Workflow", Width: 25}, // Keep this even if redundant
6 {Title: "Created At", Width: 16},
7 {Title: "Started At", Width: 16},
8 {Title: "Duration", Width: 12},
9}
Implementing Column Consistency
When implementing a detail view with a related list:
- Reference the primary view: Check which columns the primary list view uses
- Copy the column structure exactly: Same titles, same order, same widths
- Keep all columns: Don’t remove columns even if they seem redundant in the detail context
- Update row population: Ensure
updateTableRows()populates all columns correctly
❌ Wrong:
1// Workflow details view using different columns than runs list
2columns := []table.Column{
3 {Title: "Name", Width: 40}, // Different title
4 {Title: "Created At", Width: 16},
5 {Title: "Status", Width: 12}, // Different order
6 // Missing: Workflow, Started At, Duration
7}
✅ Correct:
1// Workflow details view matching runs list exactly
2columns := []table.Column{
3 {Title: "Task Name", Width: 30}, // Same titles
4 {Title: "Status", Width: 12},
5 {Title: "Workflow", Width: 25}, // Same order
6 {Title: "Created At", Width: 16},
7 {Title: "Started At", Width: 16},
8 {Title: "Duration", Width: 12}, // All columns included
9}
16. View Navigation and Modal Selector
The TUI uses a navigation stack system for drilling down into details and a modal selector for switching between primary views.
Navigation Stack Pattern
The root TUI model maintains a viewStack for back navigation:
1type tuiModel struct {
2 currentView tui.View
3 viewStack []tui.View // Stack for back navigation
4 // ...
5}
Navigating to a Detail View:
1case tui.NavigateToWorkflowMsg:
2 // Push current view onto stack
3 m.viewStack = append(m.viewStack, m.currentView)
4
5 // Create and initialize detail view
6 detailView := tui.NewWorkflowDetailsView(m.ctx, msg.WorkflowID)
7 detailView.SetSize(m.width, m.height)
8 m.currentView = detailView
9
10 return m, detailView.Init()
Navigating Back:
1case tui.NavigateBackMsg:
2 // Pop view from stack
3 if len(m.viewStack) > 0 {
4 m.currentView = m.viewStack[len(m.viewStack)-1]
5 m.viewStack = m.viewStack[:len(m.viewStack)-1]
6 m.currentView.SetSize(m.width, m.height)
7 }
8 return m, nil
In Detail Views (handle Esc key for back navigation):
1case tea.KeyMsg:
2 switch msg.String() {
3 case "esc":
4 // Navigate back to previous view
5 return v, NewNavigateBackMsg()
6 }
Modal View Selector Pattern
The modal selector allows switching between primary views using Shift+Tab:
Opening the Modal:
1case tea.KeyMsg:
2 switch msg.String() {
3 case "shift+tab":
4 // Find current view type in the list
5 for i, opt := range availableViews {
6 if opt.Type == m.currentViewType {
7 m.selectedViewIndex = i
8 break
9 }
10 }
11 m.showViewSelector = true
12 return m, nil
13 }
Modal Navigation (supports Tab, arrow keys, vim keys):
1if m.showViewSelector {
2 switch msg.String() {
3 case "shift+tab", "tab", "down", "j":
4 // Cycle forward
5 m.selectedViewIndex = (m.selectedViewIndex + 1) % len(availableViews)
6 return m, nil
7 case "up", "k":
8 // Cycle backward
9 m.selectedViewIndex = (m.selectedViewIndex - 1 + len(availableViews)) % len(availableViews)
10 return m, nil
11 case "enter":
12 // Confirm selection and switch view
13 selectedType := availableViews[m.selectedViewIndex].Type
14 if selectedType != m.currentViewType {
15 // Only switch if in a primary view
16 if m.isInPrimaryView() {
17 m.currentViewType = selectedType
18 m.currentView = m.createViewForType(selectedType)
19 m.currentView.SetSize(m.width, m.height)
20 m.showViewSelector = false
21 return m, m.currentView.Init()
22 }
23 }
24 m.showViewSelector = false
25 return m, nil
26 case "esc":
27 // Cancel without switching
28 m.showViewSelector = false
29 return m, nil
30 }
31 return m, nil
32}
Rendering the Modal:
1func (m tuiModel) renderViewSelector() string {
2 var b strings.Builder
3
4 // Use reusable header component
5 header := tui.RenderHeader("Select View", m.ctx.ProfileName, m.width)
6 b.WriteString(header)
7 b.WriteString("\n\n")
8
9 // Instructions
10 instructions := tui.RenderInstructions(
11 "↑/↓ or Tab: Navigate • Enter: Confirm • Esc: Cancel",
12 m.width,
13 )
14 b.WriteString(instructions)
15 b.WriteString("\n\n")
16
17 // View options with highlighting
18 for i, opt := range availableViews {
19 if i == m.selectedViewIndex {
20 // Highlighted option
21 selectedStyle := lipgloss.NewStyle().
22 Foreground(lipgloss.AdaptiveColor{Light: "#ffffff", Dark: "#0A1029"}).
23 Background(styles.Blue).
24 Bold(true).
25 Padding(0, 2)
26
27 b.WriteString(selectedStyle.Render(fmt.Sprintf("▶ %s - %s", opt.Name, opt.Description)))
28 } else {
29 // Non-highlighted option
30 normalStyle := lipgloss.NewStyle().
31 Foreground(styles.MutedColor).
32 Padding(0, 2)
33
34 b.WriteString(normalStyle.Render(fmt.Sprintf(" %s - %s", opt.Name, opt.Description)))
35 }
36 b.WriteString("\n")
37 }
38
39 // Footer
40 footer := tui.RenderFooter([]string{
41 "Tab: Cycle",
42 "Enter: Confirm",
43 "Esc: Cancel",
44 }, m.width)
45 b.WriteString("\n")
46 b.WriteString(footer)
47
48 return b.String()
49}
Key Principles:
- Navigation Stack: Use for hierarchical navigation (list → detail → back)
- Modal Selector: Use for switching between top-level views
- Primary View Check: Only allow view switching when not in a detail view
- Consistent Key Bindings:
Shift+Tab: Open view selectorEsc: Go back (in detail views) or cancel (in modals)Enter: Select item or confirm action- Arrow keys/vim keys: Navigate within lists and modals
Common Patterns
Formatting Utilities
Duration Formatting
1func formatDuration(ms int) string {
2 duration := time.Duration(ms) * time.Millisecond
3 if duration < time.Second {
4 return fmt.Sprintf("%dms", ms)
5 }
6 seconds := duration.Seconds()
7 if seconds < 60 {
8 return fmt.Sprintf("%.1fs", seconds)
9 }
10 minutes := int(seconds / 60)
11 secs := int(seconds) % 60
12 return fmt.Sprintf("%dm%ds", minutes, secs)
13}
ID Truncation
1func truncateID(id string, length int) string {
2 if len(id) > length {
3 return id[:length]
4 }
5 return id
6}
Status Rendering
IMPORTANT: Do not manually style statuses. Use the status utility functions:
1// For V1TaskStatus (from REST API)
2status := styles.RenderV1TaskStatus(task.Status)
3
4// The utility automatically handles:
5// - COMPLETED -> Green "Succeeded"
6// - FAILED -> Red "Failed"
7// - CANCELLED -> Orange "Cancelled"
8// - RUNNING -> Yellow "Running"
9// - QUEUED -> Gray "Queued"
10// All colors match frontend badge variants
Auto-refresh Pattern
1// Define tick message in your view file
2type tickMsg time.Time
3
4// Create tick command
5func tick() tea.Cmd {
6 return tea.Tick(5*time.Second, func(t time.Time) tea.Msg {
7 return tickMsg(t)
8 })
9}
10
11// Handle in Update
12case tickMsg:
13 // Refresh data
14 return v, tea.Batch(v.fetchData(), tick())
Debug Logging Pattern
Important: For views that make API calls or have complex state management, implement a debug logging system using a ring buffer to prevent memory leaks.
Step 1: Create Debug Logger (if not exists)
Create cmd/hatchet-cli/cli/tui/debug.go:
1package views
2
3import (
4 "fmt"
5 "sync"
6 "time"
7)
8
9// DebugLog represents a single debug log entry
10type DebugLog struct {
11 Timestamp time.Time
12 Message string
13}
14
15// DebugLogger is a fixed-size ring buffer for debug logs
16type DebugLogger struct {
17 mu sync.RWMutex
18 logs []DebugLog
19 capacity int
20 index int
21 size int
22}
23
24// NewDebugLogger creates a new debug logger with the specified capacity
25func NewDebugLogger(capacity int) *DebugLogger {
26 return &DebugLogger{
27 logs: make([]DebugLog, capacity),
28 capacity: capacity,
29 index: 0,
30 size: 0,
31 }
32}
33
34// Log adds a new log entry to the ring buffer
35func (d *DebugLogger) Log(format string, args ...interface{}) {
36 d.mu.Lock()
37 defer d.mu.Unlock()
38
39 d.logs[d.index] = DebugLog{
40 Timestamp: time.Now(),
41 Message: fmt.Sprintf(format, args...),
42 }
43
44 d.index = (d.index + 1) % d.capacity
45 if d.size < d.capacity {
46 d.size++
47 }
48}
49
50// GetLogs returns all logs in chronological order
51func (d *DebugLogger) GetLogs() []DebugLog {
52 d.mu.RLock()
53 defer d.mu.RUnlock()
54
55 if d.size == 0 {
56 return []DebugLog{}
57 }
58
59 result := make([]DebugLog, d.size)
60
61 if d.size < d.capacity {
62 // Buffer not full yet, logs are from 0 to index-1
63 copy(result, d.logs[:d.size])
64 } else {
65 // Buffer is full, logs wrap around
66 // Copy from index to end (older logs)
67 n := copy(result, d.logs[d.index:])
68 // Copy from start to index (newer logs)
69 copy(result[n:], d.logs[:d.index])
70 }
71
72 return result
73}
74
75// Clear removes all logs
76func (d *DebugLogger) Clear() {
77 d.mu.Lock()
78 defer d.mu.Unlock()
79
80 d.index = 0
81 d.size = 0
82}
83
84// Size returns the current number of logs
85func (d *DebugLogger) Size() int {
86 d.mu.RLock()
87 defer d.mu.RUnlock()
88 return d.size
89}
90
91// Capacity returns the maximum capacity
92func (d *DebugLogger) Capacity() int {
93 return d.capacity
94}
Step 2: Integrate Debug Logger in Your View
1type YourView struct {
2 BaseModel
3 // ... other fields
4 debugLogger *DebugLogger
5 showDebug bool // Whether to show debug overlay
6}
7
8func NewYourView(ctx ViewContext) *YourView {
9 v := &YourView{
10 BaseModel: BaseModel{
11 Ctx: ctx,
12 },
13 debugLogger: NewDebugLogger(5000), // 5000 log entries max
14 showDebug: false,
15 }
16
17 v.debugLogger.Log("YourView initialized")
18
19 return v
20}
Step 3: Add Debug Logging Throughout View
1// Log important events
2func (v *YourView) fetchData() tea.Cmd {
3 return func() tea.Msg {
4 v.debugLogger.Log("Fetching data...")
5
6 // Make API call
7 response, err := v.Ctx.Client.API().SomeEndpoint(...)
8
9 if err != nil {
10 v.debugLogger.Log("Error fetching data: %v", err)
11 return dataMsg{err: err}
12 }
13
14 v.debugLogger.Log("Successfully fetched %d items", len(response.Items))
15 return dataMsg{data: response.Items}
16 }
17}
Step 4: Add Toggle Key Handler
1func (v *YourView) Update(msg tea.Msg) (View, tea.Cmd) {
2 switch msg := msg.(type) {
3 case tea.KeyMsg:
4 switch msg.String() {
5 case "d":
6 // Toggle debug view
7 v.showDebug = !v.showDebug
8 v.debugLogger.Log("Debug view toggled: %v", v.showDebug)
9 return v, nil
10 case "c":
11 // Clear debug logs (only when in debug view)
12 if v.showDebug {
13 v.debugLogger.Clear()
14 v.debugLogger.Log("Debug logs cleared")
15 }
16 return v, nil
17 }
18 }
19 // ... rest of update logic
20}
Step 5: Implement Debug View Rendering
1func (v *YourView) View() string {
2 if v.Width == 0 {
3 return "Initializing..."
4 }
5
6 // If debug view is enabled, show debug overlay
7 if v.showDebug {
8 return v.renderDebugView()
9 }
10
11 // ... normal view rendering
12}
13
14func (v *YourView) renderDebugView() string {
15 logs := v.debugLogger.GetLogs()
16
17 // Header
18 headerStyle := lipgloss.NewStyle().
19 Bold(true).
20 Foreground(styles.AccentColor).
21 BorderStyle(lipgloss.NormalBorder()).
22 BorderBottom(true).
23 BorderForeground(styles.AccentColor).
24 Width(v.Width-4).
25 Padding(0, 1)
26
27 header := headerStyle.Render(fmt.Sprintf(
28 "Debug Logs - %d/%d entries",
29 v.debugLogger.Size(),
30 v.debugLogger.Capacity(),
31 ))
32
33 // Log entries
34 logStyle := lipgloss.NewStyle().
35 Padding(0, 1).
36 Width(v.Width - 4)
37
38 var b strings.Builder
39 b.WriteString(header)
40 b.WriteString("\n\n")
41
42 // Calculate how many logs we can show
43 maxLines := v.Height - 8 // Reserve space for header, footer, controls
44 if maxLines < 1 {
45 maxLines = 1
46 }
47
48 // Show most recent logs first
49 startIdx := 0
50 if len(logs) > maxLines {
51 startIdx = len(logs) - maxLines
52 }
53
54 for i := startIdx; i < len(logs); i++ {
55 log := logs[i]
56 timestamp := log.Timestamp.Format("15:04:05.000")
57 logLine := fmt.Sprintf("[%s] %s", timestamp, log.Message)
58 b.WriteString(logStyle.Render(logLine))
59 b.WriteString("\n")
60 }
61
62 // Footer with controls
63 footerStyle := lipgloss.NewStyle().
64 Foreground(styles.MutedColor).
65 BorderStyle(lipgloss.NormalBorder()).
66 BorderTop(true).
67 BorderForeground(styles.AccentColor).
68 Width(v.Width-4).
69 Padding(0, 1)
70
71 controls := footerStyle.Render("d: Close Debug | c: Clear Logs | q: Quit")
72 b.WriteString("\n")
73 b.WriteString(controls)
74
75 return b.String()
76}
Step 6: Update Footer Controls
Add debug controls to your normal view footer:
1controls := footerStyle.Render("↑/↓: Navigate | r: Refresh | d: Debug | q: Quit")
Benefits:
- Fixed-size ring buffer prevents memory leaks
- Thread-safe with mutex protection
- Toggle on/off without restarting TUI
- Helps diagnose API issues and state changes
- No performance impact when not viewing logs
Testing Approach
Dummy Data Generation
During development, create dummy data generators in your view file:
1func generateDummyData() []YourDataType {
2 now := time.Now()
3 return []YourDataType{
4 {
5 Field1: "value1",
6 Field2: "value2",
7 CreatedAt: now.Add(-5 * time.Minute),
8 },
9 // ... more dummy items
10 }
11}
Example Reference
File Structure Example
cmd/hatchet-cli/cli/
├── tui.go # Root TUI command
└── views/
├── view.go # View interface and base types
├── tasks.go # Tasks view implementation
└── workflows.go # Workflows view implementation (future)
Complete View Example
See cmd/hatchet-cli/cli/tui/tasks.go for a complete implementation.
Compilation and Testing
CRITICAL: Always ensure the CLI binary compiles before considering work complete.
Compilation Check
After implementing or modifying any view:
1# Build the CLI binary
2go build -o /tmp/hatchet-test ./cmd/hatchet-cli
3
4# Check for errors
5echo $? # Should be 0 for success
Common Compilation Issues
UUID Type Mismatches
1// ❌ Wrong - string to UUID 2client.API().SomeMethod(ctx, client.TenantId(), ...) 3 4// ✅ Correct - parse and convert 5tenantUUID, err := uuid.Parse(client.TenantId()) 6if err != nil { 7 return msg{err: fmt.Errorf("invalid tenant ID: %w", err)} 8} 9client.API().SomeMethod(ctx, openapi_types.UUID(tenantUUID), ...)Required Imports
1import ( 2 "github.com/google/uuid" 3 openapi_types "github.com/oapi-codegen/runtime/types" 4)Type Conversions for API Params
*int64not*intfor offset/limittime.Timenot*time.Timefor Since parameter (check the generated types)openapi_types.UUIDfor tenant and workflow IDs- Check
pkg/client/rest/gen.gofor exact parameter types
Pointer Helper Functions
1func int64Ptr(i int64) *int64 { 2 return &i 3}
Testing Workflow
Compilation Test
1go build -o /tmp/hatchet-test ./cmd/hatchet-cliLinting Test
After the build succeeds, run the linting checks:
1task pre-commit-runContinue running this command until it succeeds. Fix any linting issues that are reported before proceeding.
Basic Functionality Test
1# Test with profile selection 2/tmp/hatchet-test tui 3 4# Test with specific profile 5/tmp/hatchet-test tui --profile your-profileError Handling Test
- Try without profiles configured
- Try with invalid profile
- Test keyboard controls (q, r, arrows)
Visual/Layout Testing
When implementing a new view:
- Test at various terminal sizes (minimum 80x24)
- Ensure header and footer are always visible
- Verify instructions are clear and helpful
- Check that navigation controls are consistent with other views
- Test with both light and dark terminal backgrounds
- Verify all reusable components render correctly
Checklist for New TUI Views
Before You Start
- Find the corresponding frontend view in
frontend/app/src/pages/main/v1/ - Identify column structure and API calls from frontend
- Note the exact API endpoint and parameters used
Creating the View
- Create new file in
cmd/hatchet-cli/cli/tui/{viewname}.go - Add required imports (including
uuidandopenapi_typesif needed) - Define view struct that embeds
BaseModel - Create
NewYourView(ctx ViewContext)constructor - Implement
Init()method - Implement
Update(msg tea.Msg)method - Implement
View()method following standard structure - Implement
SetSize(width, height int)method - USE REUSABLE COMPONENTS:
RenderHeader(),RenderInstructions(),RenderFooter() - DO NOT copy-paste header/footer styling code
- Apply Hatchet theme colors and styles for custom components only
- Implement view-specific keyboard controls
- Document all keyboard controls in footer using
RenderFooter() - Use appropriate REST API types
- Add error handling using
BaseModel.HandleError() - Add responsive layout (handle WindowSizeMsg)
API Integration
- Parse tenant ID to UUID if needed
- Use correct parameter types (
*int64,time.Time, etc.) - Handle API response errors
- Format data for table display
- Add loading states and error display
Integration and Testing
- Import view in
tui.go - Update
newTUIModel()to instantiate your view - Compile the CLI binary (
go build ./cmd/hatchet-cli) - Fix any compilation errors
- Test basic functionality with real profile
- Test error cases (no profile, invalid profile)
- Test keyboard controls (q, r, arrows)
- Update TUI command documentation
Best Practices
- CRITICAL: Use reusable components (
RenderHeader,RenderInstructions,RenderFooter) - NEVER copy-paste header/footer styling code - this violates DRY principle
- Keep view logic isolated in the view file
- Use
ViewContextto access client and profile info - Handle all messages gracefully (return
v, nilfor unhandled) - Always check
v.Width == 0before rendering - Use consistent styling with other views (use Hatchet theme colors)
- Document ALL keyboard controls in footer using
RenderFooter() - Follow the standard view structure (header, instructions, content, footer)
- Always verify compilation before submitting
Post-Implementation
- Update this skill document with any new patterns or learnings discovered
- Document any issues encountered and their solutions
- Add any new utility functions or patterns to the appropriate sections
- Verify all code examples and file paths are accurate
Lessons Learned & Updates
This section documents recent learnings and updates to maintain accuracy.
Recent Updates
- 2026-01-10: Major updates based on workers view implementation and bug fixes:
- Added workers list view and worker details view as reference implementations
- Updated common REST API types list to include Worker, WorkerRuntimeInfo, Workflow
- Documented detail view header patterns (showing specific resource names in titles)
- Added section on filtering with multi-select forms and custom key maps
- Documented per-cell table styling using TableWithStyleFunc wrapper
- Added examples of status badge rendering in detail views
- Documented navigation messages (NavigateToWorkerMsg pattern)
- Added column alignment best practices (matching header format strings to row rendering)
- Workflow TUI implementation updates:
- Updated header component documentation: ALL headers (primary, detail, modal) now use highlight color for consistency
- Added
RenderHeaderWithViewIndicator()for primary views (shows just view name, non-repetitive) - Added section 14: Table Height Calculations and Layout Optimization (height - 12 vs height - 16)
- Added section 15: Column Consistency Between Related Views (critical for UX)
- Added section 16: View Navigation and Modal Selector patterns
- Documented modal selector with Shift+Tab and arrow key support
- Documented navigation stack pattern for detail view drilling
- 2026-01-09: Added self-updating instructions and verification checklist
- Document initialized with comprehensive TUI view building guidelines
Known Issues & Solutions
Issue: Table Column Alignment Mismatches
Problem: Header columns don’t align with table rows due to format string width mismatch.
Example: In run details tasks tab, header used %-3s for selector column but rows only rendered 2 characters ("▸ " or " “), causing status column and all subsequent columns to be misaligned.
Solution: Ensure header format string widths exactly match row rendering:
1// Header format - 2 chars for selector to match "▸ " or " "
2headerStyle.Render(fmt.Sprintf("%-2s %-30s %-12s", "", "NAME", "STATUS"))
3
4// Row rendering - also 2 chars
5if selected {
6 b.WriteString("▸ ") // 2 characters
7} else {
8 b.WriteString(" ") // 2 characters
9}
Prevention: Always count the exact characters rendered in rows and match header format widths precisely.
Issue: Detail View Headers Too Generic
Problem: Detail views showed generic titles like “Task Details” or “Workflow Run Details” without identifying the specific resource being viewed.
Solution: Include the resource name in the header title:
1// For task details
2title := "Task Details"
3if v.task != nil {
4 title = fmt.Sprintf("Task Details: %s", v.task.DisplayName)
5}
6
7// For workflow details
8title := "Workflow Details"
9if v.workflow != nil {
10 title = fmt.Sprintf("Workflow Details: %s", v.workflow.Name)
11}
12
13// For run details
14title := "Run Details"
15if v.details != nil && v.details.Run.DisplayName != "" {
16 title = fmt.Sprintf("Run Details: %s", v.details.Run.DisplayName)
17}
Pattern: Use format "{View Type} Details: {Resource Name}" for all detail views.
Issue: Filter Form Navigation Conflicts
Problem: Global Shift+Tab handler for view switching conflicts with form navigation, preventing Tab/Shift+Tab from working in filter modals.
Solution: Process filter form messages BEFORE checking global key handlers:
1// In Update(), handle form FIRST
2if v.showingFilter && v.filterForm != nil {
3 form, cmd := v.filterForm.Update(msg)
4 if f, ok := form.(*huh.Form); ok {
5 v.filterForm = f
6
7 if v.filterForm.State == huh.StateCompleted {
8 // Apply filters
9 v.selectedStatuses = v.tempStatusFilters
10 v.showingFilter = false
11 v.updateTableRows()
12 return v, nil
13 }
14
15 // Check for ESC to cancel
16 if keyMsg, ok := msg.(tea.KeyMsg); ok {
17 if keyMsg.String() == "esc" {
18 v.showingFilter = false
19 return v, nil
20 }
21 }
22 }
23 return v, cmd
24}
25
26// THEN handle global keys
27switch msg := msg.(type) {
28case tea.KeyMsg:
29 switch msg.String() {
30 case "shift+tab":
31 // Global view switcher
32 }
33}
Pattern: Always delegate to active modal/form components before processing global keyboard shortcuts.
Issue: Filtered Workers Not Reflected in Navigation
Problem: When navigating to worker details via Enter key, code used unfiltered v.workers list instead of filtered list, causing cursor index mismatch with displayed rows.
Solution: Use the filtered/displayed list for navigation:
1case "enter":
2 // Use filteredWorkers, not workers
3 if len(v.filteredWorkers) > 0 {
4 selectedIdx := v.table.Cursor()
5 if selectedIdx >= 0 && selectedIdx < len(v.filteredWorkers) {
6 worker := v.filteredWorkers[selectedIdx]
7 workerID := worker.Metadata.Id
8 return v, NewNavigateToWorkerMsg(workerID)
9 }
10 }
Pattern: Always use the same data source for rendering and navigation. If you cache filtered data for StyleFunc, use that cached data for navigation too.
Future Improvements
(This section will track potential improvements to the TUI system or this skill document)
What Users Are Saying
Real feedback from the community
Environment Matrix
Dependencies
Framework Support
Context Window
Security & Privacy
Information
- Author
- hatchet-dev
- Updated
- 2026-01-30
- Category
- cli-tools
Related Skills
Build Tui View
Provides instructions for building Hatchet TUI views in the Hatchet CLI.
View Details →Angular Modernization
Modernizes Angular code such as components and directives to follow best practices using both …
View Details →Angular Modernization
Modernizes Angular code such as components and directives to follow best practices using both …
View Details →