(v2) Proposal: program execution flow

[aymanbagabas]

Currently, Bubble Tea programs has the following methods to start and run a program.

• Start() error starts the program and waits without returning a final model deprecated
• Run() (Model, error) starts the program and waits
• Wait() waits for the program to finish (the aforementioned ones already wait for the program to exit, this is redundant)
• Kill() kills the program (currently it only cancels the context) Related issues: Recover panics from within cmds goroutines #234 After a panic() the terminal input does not show #1127

To keep the API similar to other Go packages, we could change the API to be as follows:

• Start() error starts the program and event loop
• Wait() error waits for the event loop to finish and exit
• Run() error becomes a helper that starts and waits for the program
• Kill() error kills the program and forces the event loop to stop

With this, we would expose a program.Model that has the final model after the program exits. During the lifetime of the program, program.Model would be nil. This is similar to the exec.Cmd API in the standard library.

[tauraamui]

Presumably this would result in needing to provide a V2 version of the library, how would you most prefer to do this? Via a V2 branch or a v2 submodule?

[caarlos0]

@aymanbagabas the only problem I see with this is that people might still be using the currently deprecated Start(), which waits for the program to quit.

If we do this new proposed API, Start becomes "undeprecated", with different behavior.
Not sure how fine this is, but would def have to be very specific about this.
Another idea would be to make a "tealint" of sort, which check for this kind of stuff (and maybe more?) - seems like a rather big project though.

[caarlos0]

Presumably this would result in needing to provide a V2 version of the library, how would you most prefer to do this? Via a V2 branch or a v2 submodule?

Definitely for v2, haven't decided on specifics yet, as it also depends on whether we'll want to continue maintaining v1, e.g., with GoReleaser I simply said "main is now v2", changed the module paths, and that was it.

[dolmen]

What about changing Model[T] from an interface to a struct? I'm asking because the Program[T] implementation in #1298 uses the methods of the model as functions, so there is no need to force to attach those functions to a type.

type Model[T any] struct {
	// Init is the first function that will be called. It returns an optional
	// initial command. To not perform an initial command return nil.
	Init func() (T, Cmd)

	// Update is called when a message is received. Use it to inspect messages
	// and, in response, update the model and/or send a command.
	Update func(T, Msg) (T, Cmd)

	// View renders the program's UI, which is just a [fmt.Stringer]. The view
	// is rendered after every Update.
	// The main model can return a [Frame] to set the cursor position and
	// style.
	View func(T) fmt.Stringer
}

The following function would allow to convert the old style to the new style:

func NewModel[T interface {
	Init() (T, Cmd)
	Update(Msg) (T, Cmd)
	View() fmt.Stringer
}](m T) Model[T] {
	return Model[T]{
		Init:   m.Init,
		Update: T.Update,
		View:   T.View,
	}
}

On the Go playground: https://go.dev/play/p/nU6YAeIjavD

Note: In general, generics are a way to avoid use of interfaces and dynamic calls. Every parametrized interface type is a red herring: there is way to redesign using parametrized concrete types instead.

[dolmen]

To go further, here is another design where the Program is given directly the Init function that instantiate the model which then has only two functions: Update and View.

type Model[State any] struct {
	// Update is called when a message is received. Use it to inspect messages
	// and, in response, return an updated state and/or send a command.
	Update func(State) (State, Cmd)

	// View renders the program's UI, which is just a [fmt.Stringer]. The view
	// is rendered after every Update.
	// The main model can return a [Frame] to set the cursor position and
	// style.
	View func(State) fmt.Stringer
}

// InitModel initializes a model and returns its initial state. It also returns an optional
// initial command. To not perform an initial command return nil.
type InitModel[State any] = func() (Model[State], Cmd)

// NewProgram creates a new Program.
func NewProgram[State any](initModel InitModel[State]) *Program[State]

https://go.dev/play/p/z4TmJm3ZkGC

[meowgorithm]

Hey @dolmen! Funny enough we explored something along these lines in #1298. There are things we really liked about it, it but ultimately we felt it complicated things too much and have put it on the shelf for now.

Speaking of which, we're also not planning on exploring the main design in this issue further, so I'm going to close it accordingly. Please do feel free to continue discussing it if you'd like, however.