add a CmdFunc function

[tgirod]

Here is a little helper function that I would find useful to have in bubbletea:

func CmdFunc(msg tea.Msg) tea.Cmd {
    return func() { return msg }
}

It is very similar to http.HandlerFunc and serves a similar purpose, I think.

[meowgorithm]

Hi there! Curious, what's your use case? Also, assuming you meant this, right?

func CmdFunc(msg tea.Msg) tea.Cmd {
    return func() tea.Msg { return msg }
}

[tgirod]

@meowgorithm for my first application, my main model contains a stack of models. The idea is that Update and View are delegating the work to the top-most model of the stack, appart from a few navigation messages that allows to push or pop models from the stack.

// Update takes this model and push it on the stack
type OpenMsg tea.Model

// Update removes topmost model from the stack
type CloseMsg struct{}

// some model Foo

func (f Foo) Update(tea.Msg) (tea.Model, tea.Cmd) {

    // some condition where we want to open model Bar
    bar := OpenMsg(Bar{}) // my new model to display
    return CmdFunc(bar) // send the model back to the Update loop
}

As I find myself turning a tea.Model into a tea.Cmd, I thought it would be useful to have this helper function. Now, maybe I'm approaching the problem the wrong way, and I shouldn't have to do that ... In which case I'm eager to be corrected! :)

[meowgorithm]

So logic dictates that you shouldn't need to use a Cmd to simply send data to different parts of your application because that data already exists in the very Update from which you're returning the Cmd.

That said, while this is probably fine to use in practicality (we see it every so often) it does incur an unnecessary loop through the runtime. Because of that, we'd prefer not to include it in the core. In other words, it's techincally an antipattern, and actually a common one seen in The Elm Architecture, the design upon which Bubble Tea is built.

[tgirod]

So logic dictates that you shouldn't need to use a Cmd to simply send data to different parts of your application because that data already exists in the very Update from which you're returning the Cmd.

Thanks for your input! I think I oversimplified my example, and in that case CmdFunc is effectively useless. I'll try to do better this time.

// main model
type Main struct {
    stack []tea.Model
}

// first sub-model
type Screen1 struct {}

// second sub-model
type Screen2 struct{}

In Main.Update, messages are passed to the top-most model in the stack, appart from special messages to push/pop models on the stack.

Now, Let's say Screen1 is the top-most model in the stack. Following an event, some code in Screen1.Update creates a Screen2 model which should be pushed to the stack. So, I would say the data exists in Screen1.Update, but not in Main.Update, right?

Or am I creating components, and I should avoid doing that, as ELM's documentation suggests?

[bashbunni]

Hey @tgirod when you say data I'm assuming you mean Screen2 and all its data?
Typically what you'd want to do here is manage the state of the program in the main model, then change what's being shown from View based on the main model's state. In this case you would want to control the creation of new screens in your main model's Update. If the new Screen2 is created while you're looking at Screen1 don't worry, you can still handle the tea.Msg in the main Update and just trigger the tea.Cmd from your Screen1 Update. I hope this answers your question. Please let me know if not, and I'll be happy to try again 😄

[tgirod]

Maybe my problem comes from having wrong asumptions on how to write a bubbletea app. Are you telling my my application should be more monolithic, with a my main model's managing everything directly instead of delegating to some sub-models ?

[meowgorithm]

Hey @tgirod! Do you have source code for a more complete application where you're using CmdFunc, described above? It'll be a lot easier to reason about this if we can see the full context of how you're going about things.

But to your question, it's perfectly reasonable nest data in sub-models.

[tgirod]

Hey @meowgorithm! I'm currently writing a more concrete example, will hopefully post it soon...

[dcopso]

I wonder if this question is actually about how to handle the common "data down, events up" pattern that we see in reactive systems like Elm and React.

Consider the simplified example below -- it is a simple program with a bubbles textinput and an output component which capitalizes the user's input when they hit ENTER. We have a textinput model and an output model, and a top model with an event handler that listens to a subset of keys and passes the rest to the children models.

What is the idiomatic pattern for sending an event from myInput.Update to myOutput.Update so that the output component can update state? These models do not have references to the other's model.

The only elegant solution I see is to use @tgirod's CmdFunc-like method to generate a message for the top-level Update handler. Any other pattern requires global state -or- a top-level Update handler that understands the state of all child components.

Is there a cleaner solution?

Thanks.

// event generated by input component
type inputValueChanged string

// update handler for input component
func (m myInput) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.Type {
		case tea.KeyEnter:
			log.Printf("Value: %s", m.textInput.Value())
			return m, func() tea.Msg { return inputValueChanged(m.textInput.Value()) }  // <--- is this idiomatic?
		}
	}
	var cmd tea.Cmd
	m.textInput, cmd = m.textInput.Update(msg)
	return m, cmd
}

func (m myInput) View() string {
	return m.textInput.View()
}

// output component
type myOutput string

// listens for inputValueChanged events
func (m myOutput) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case inputValueChanged:
		m = myOutput(strings.ToUpper(string(msg)))
	}
	return m, nil
}

func (m myOutput) View() string {
	return string(m)
}

// top-level model listens only for quit commands
func (m topModel) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.Type {
		case tea.KeyEsc, tea.KeyCtrlC:
			return m, tea.Quit
		}
	}
	var cmds []tea.Cmd
	var cmd tea.Cmd
	m.inputModel, cmd = m.inputModel.Update(msg)
	if cmd != nil {
		cmds = append(cmds, cmd)
	}
	m.outputModel, cmd = m.outputModel.Update(msg)
	if cmd != nil {
		cmds = append(cmds, cmd)
	}
	return m, tea.Batch(cmds...)
}

Full .go file

package main

import (
	"fmt"
	"github.com/charmbracelet/bubbles/textinput"
	tea "github.com/charmbracelet/bubbletea"
	"log"
	"strings"
)

type (
	errMsg error
)

type inputValueChanged string

type myInput struct {
	textInput textinput.Model
	err       error
}

func initialMyInput() tea.Model {
	ti := textinput.New()
	ti.Placeholder = "Foo"
	ti.Focus()
	return myInput{
		textInput: ti,
		err:       nil,
	}
}

func (m myInput) Init() tea.Cmd {
	return textinput.Blink
}

func (m myInput) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.Type {
		case tea.KeyEnter:
			log.Printf("Value: %s", m.textInput.Value())
			return m, func() tea.Msg { return inputValueChanged(m.textInput.Value()) }
		}
	case errMsg:
		panic(msg)
	}
	var cmd tea.Cmd
	m.textInput, cmd = m.textInput.Update(msg)
	return m, cmd
}

func (m myInput) View() string {
	return m.textInput.View()
}

type myOutput string

func (m myOutput) Init() tea.Cmd {
	return nil
}

func (m myOutput) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case inputValueChanged:
		m = myOutput(strings.ToUpper(string(msg)))
	}
	return m, nil
}

func (m myOutput) View() string {
	return string(m)
}

type topModel struct {
	inputModel  tea.Model
	outputModel tea.Model
}

func initialTopModel() topModel {
	return topModel{
		inputModel:  initialMyInput(),
		outputModel: myOutput(""),
	}
}

func (m topModel) Init() tea.Cmd {
	return tea.Batch(m.inputModel.Init(), m.outputModel.Init())
}

func (m topModel) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.Type {
		case tea.KeyEsc, tea.KeyCtrlC:
			return m, tea.Quit
		}
	}
	var cmds []tea.Cmd
	var cmd tea.Cmd
	m.inputModel, cmd = m.inputModel.Update(msg)
	if cmd != nil {
		cmds = append(cmds, cmd)
	}
	m.outputModel, cmd = m.outputModel.Update(msg)
	if cmd != nil {
		cmds = append(cmds, cmd)
	}
	return m, tea.Batch(cmds...)
}

func (m topModel) View() string {
	return fmt.Sprintf("\n\nInput: %s\n\nOutput: %s\n\n", m.inputModel.View(), m.outputModel.View())
}

func main() {
	f, err := tea.LogToFile("debug.log", "debug")
	if err != nil {
		panic(err)
	}
	defer f.Close()
	topModel := initialTopModel()
	p := tea.NewProgram(topModel)
	if _, err := p.Run(); err != nil {
		panic(err)
	}
}

[bashbunni]

Typically you'll have a main model that routes traffic to your sub-models as needed and handles change in focused elements or state. That's definitely the easiest and simplest way to go about it from what I've seen.

[meowgorithm]

The other thought here is that it's often easier to simply not nest models when you have different parts of the application that depend on the same general data. For example, this is how I'd probably layout a file browsing application:

func (Model) Init() tea.Cmd

func (Model) Update(tea.Msg) (tea.Model, tea.Cmd)
func (*Model) updateFileListing(tea.Msg) tea.Cmd
func (*Model) updateFileViewer(tea.Msg) tea.Cmd

func (Model) View() string
func (Model) viewFileBrowser() string
func (Model) viewFileViewer() string

Because both the file browser and file viewer essentially need the same dataset there's a lot less need here to pass data around and keep everything in sync.

[dcopso]

Thanks for the thoughtful responses. I totally agree that most applications can probably get by with the monolithic approach. But, what are common patterns when the application gets too complicated for that?

I believe ours will benefit from looser coupling. We have N interaction screens and we'd like the screen's models to be responsible for managing async computations that may or may not react to changes on other screens, without any explicit knowledge of those other screens.

Is there any problem with using tea.Cmd's for propagating these kinds of semantic events? I see in the docs that it is explicitly discouraged. Would building our own event that feeds into Program.Send be better for some reason than using a CmdFunc?

Thanks.

[tgirod]

If ScreenA produces events that might trigger something in ScreenB, you are half-way to recursive dependencies and your event should probably be defined at a higher level in your program's hierarchy.

During this program's development, I tried several times to abstract away some functionnalities in some kind of bubbletea component, but it felt cumbersome and I abandonned it. I guess bbtea's design does not lend well to composition. Maybe the lack of generics (when bbtea was created) and the lack of union types makes it less composable than ELM for example.