Input Data Structures

Relevant source files

The following files were used as context for generating this wiki page:

• input.go
• main.go
• README.md
• go.mod
• go.sum

The input data structures in this project facilitate a terminal-based wizard interface. This system is built using the Bubble Tea framework to manage state and Lip Gloss for layout styling. The architecture revolves around an abstraction layer for terminal inputs, allowing the application to handle different types of user data entry (short text vs. long text) through a unified interface.

Sources: README.md:1-20, main.go:1-12

Core Abstraction: The Input Interface

The project defines a generic Input interface to wrap different Bubble Tea components that do not inherently implement the tea.Model interface in a way that fits this specific wizard flow. This abstraction allows the Main application state to interact with varying input types without knowing their underlying implementation details.

The diagram shows how the Input interface provides a common set of methods implemented by specialized field types.
Sources: input.go:9-17

Field Implementations

The system currently supports two concrete implementations of the Input interface:

Implementation	Internal Component	Purpose
shortAnswerField	textinput.Model	Used for single-line text entry (e.g., names, short identifiers).
longAnswerField	textarea.Model	Used for multi-line text entry (e.g., quotes, descriptions).

Sources: input.go:22-114

Data Modeling

The wizard's state is structured around a central Main struct that manages a sequence of Question objects. Each Question encapsulates the prompt text, the user's response, and the specific input component used to capture that response.

Question Structure

The Question struct is the primary unit of data for the wizard.

type Question struct {
	question string
	answer   string
	input    Input
}

Sources: main.go:33-37

Main Application State

The Main struct tracks the progress through the questionnaire and manages global terminal dimensions.

Field	Type	Description
styles	*Styles	Contains Lip Gloss styling definitions for the UI.
index	int	Tracks the current question index in the sequence.
questions	[]Question	A slice containing all defined wizard steps.
width	int	The current terminal window width.
height	int	The current terminal window height.
done	bool	Indicates if the user has completed all questions.

Sources: main.go:24-31

Flow and Lifecycle

The input data flows from the user into the current Input component, and upon the "enter" key event, it is saved into the answer field of the Question struct.

This flow illustrates the progression from individual input capture to final data aggregation.
Sources: main.go:72-101

Component Initialization

The project uses factory functions to instantiate specific question types with pre-configured input fields.

• newShortQuestion(q string): Initializes a Question with a shortAnswerField.
• newLongQuestion(q string): Initializes a Question with a longAnswerField.

Sources: main.go:43-55

UI Styling and Presentation

Input presentation is handled by the Styles struct and Lip Gloss. The input fields are rendered inside a border with specific padding and width constraints.

func DefaultStyles() *Styles {
	s := new(Styles)
	s.BorderColor = lipgloss.Color("36")
	s.InputField = lipgloss.NewStyle().
        BorderForeground(s.BorderColor).
        BorderStyle(lipgloss.NormalBorder()).
        Padding(1).
        Width(80)
	return s
}

Sources: main.go:14-22

The final view iterates through the questions slice to display the accumulated question and answer pairs once the wizard is complete.
Sources: main.go:103-125

Conclusion

The "Input Data Structures" within this project provide a robust framework for building sequential terminal wizards. By abstracting specific Bubble Tea components into a unified Input interface, the system achieves a clean separation between the wizard's navigation logic and the specific mechanics of data entry. This structure ensures that adding new input types (such as checkboxes or selection menus) requires minimal changes to the core application state management.