What’s the point of Commands?

[fortuna]

Given that we can start Goroutines in the Update method, and call Send(msg), doesn’t that remove the need for commands? Removing the indirection seems easier to understand.

It also seems to remove the need for Init, reducing the API.

[lrstanley]

I can't speak for the Charm team, but I personally think it boils down to a few problems:

1. While you totally can spin up goroutines inside of Update(), you probably shouldn't in 99% of scenarios, as it breaks out of the ELM architecture, because it breaks out of the scope of only updating state from inside of Update().
   • You could avoid updating state in that goroutine, but that would have to be something you hold yourself to; it's harder to keep that constraint when you have other people contributing to the code and don't fully understand that.
   • It's easier to footgun yourself and have references to the original model that may no longer exist (e.g. recreating child models), and still try and update state outside of the scope of Update().
   • Commands help in isolating the state updates from i/o and other computational/complex logic. It promotes good hygiene in keeping state isolated from view logic and business logic.
   • It allows the parent to more easily order the operations that occur, with tea.Batch() vs tea.Sequence(). If you spin up a goroutine inside of a child Update() method, the parent can't control if what you're doing is synchronous or asynchronous, and forcing things to be synchronous is sometimes required.
2. Send() is only available if you have access to the tea.Program, which 99% of your app probably shouldn't have access to (or need access to). If you're able to call methods on the resulting tea.Program, it means could could do a few things too easily:
   • Bypass certain state updates or commands within parent components, from child components. Sometimes you want to prevent a child component from returning a specific command upwards (bubbling up the command through the stack), and you can do this by ignoring the command from that component, and not returning it.
   • You can kill or close the TUI without the rest of the model tree being able to cleanup its state.
   • Generally speaking, global state should be discouraged, which allowing children models to access the tea.Program feels like it falls under that category.
   • It's better to return a command, that can do that external logic, then return a message which is then used to update the state, assuming the trigger of that logic happens from an event passed into Update().
   • Send() still makes sense for non-UI based updates outside of the scope of the TUI -- I think that's what its intended purpose was, not to be used by the TUI itself.
   • Using Send() directly also makes it difficult to externalize a component into a separate reusable package. It's why most 3rd party component libraries for bubbletea don't accept tea.Program as an argument.
3. It also seems to remove the need for Init, reducing the API. -- Init() in particular is designed the way it is, because it's the only thing that's not directly triggered by an event. Update() should only be called based off another event (this is to ensure it's purely reactive-based state updates, again -- ELM architecture), so if your child component needs some initializer to begin triggering updates for various things, it can do that from Init().
   • An example: the textinput bubble from the charmbracelet/bubbles package, uses Init() to send an initial cursor.BlinkMsg, so the component can begin blinking the cursor.
     • If it doesn't do it in Init(), when would it get the chance to do it via Update()? Would you just do it based on the first event that was received? If so, now you're triggering logic and/or state on a message that's unrelated to the passed in event, so a parent model, if ignoring a specific command, might end up ignoring the wrong thing. It also makes it hard to track down when state changes occur, because that logic isn't tied to an event and/or command, so it could technically happen at any time.

Generally speaking, Update() should only ever operate/change state based on the given message that is passed in, and not have asynchronous logic that is not directly related to the message. This makes the code much easier to reason about, and reduces all sorts of weird bugs you may encounter with state updates, especially because the root model does not return a pointer.

A lot of what I mentioned above is related not purely to the root model, and more using the same architecture throughout the application, with child models. While children technically don't have to follow the tea.Model interface (or slightly variations of it), it's generally accepted as the standard to keep within the ELM-architecture. To bypass these problems would effectively be dropping the ELM architecture to a large degree. Remember that the ELM architecture is more than just separating concerns into Model-View-Controller (MVC).

Some of the above isn't described well (or at all) at the moment in the bubbletea README, so there are probably some improvements that could be made. I.e. a further breakdown of the ELM architecture, its associated benefits for libraries like bubbletea, and general guidance which helps explain reasoning.

[fortuna]

Thanks for the response.

You point [1] doesn't actually address my comment. I'm not arguing for changing state in the go routines. All state updates should still be done in Update(). But the Goroutines can send a message that triggers the Update() call (using Send(msg)). There's no "foot gunning" when you do that.

On [2], you don't need globals, and you don't need the tea.Program. You just need to inject the Send(msg) function into your model from the root. You can easily have external components if they take a Send(msg) function.

On [3], when you create the model, you also do all the initialization you need. No need for a separate Init method. In fact, separating creation and initialization is usually bad practice, as it leaves the object in an invalid state until Init is called.

[fortuna]

To illustrate what I mean better, I want to create an app that issues various network requests.
On Update, if the msg for the "Submit" button press is received, I can start each request on its on goroutine, and update the model to represent the in-flight requests. As the responses are received, they can Send a message of response received, which will trigger the Update call to handle it.

You could imagine a variation where the requests are sent on a regular basis from the start. In that case I could just start a goroutine when the program starts that sends a message on a timer to trigger the request.

There's no Command and Init in this implementation, which, in my opinion, makes it easier to understand. But perhaps I'm missing something.

[fortuna]

For context: The bigger the interface, the weaker the abstraction.

[lrstanley]

You point [1] doesn't actually address my comment. I'm not arguing for changing state in the go routines. All state updates should still be done in Update(). But the Goroutines can send a message that triggers the Update() call (using Send(msg)). There's no "foot gunning" when you do that.

I'm not stating you are, I'm suggesting that there is a huge side effect. Defensive APIs can help reduce developer error and implementation issues, so although you might not do that, there is nothing preventing someone from trying to do it in that scenario. No guardrails whatsoever.

On [2], you don't need globals, and you don't need the tea.Program. You just need to inject the Send(msg) function into your model from the root. You can easily have external components if they take a Send(msg) function.

You have to have access to tea.Program to pass that function into the root model, which means you're closely coupling the implementation (the root model) with the execution of the implementation (tea.Program). That's not necessarily an issue, because if the approach that bubbletea used had changed, Send could just be made accessible in an abstract way (almost like commands 😁), so that's in itself isn't necessarily an issue. However, it also means you have to pass that Send function into all initializers, because you don't know if something will need access to it indirectly in a child, effectively function coloring everything. It also means there is no longer a single entry/exit point for updates, which in part breaks ELM principles, in addition to all of the previous problems I mentioned.

On [3], when you create the model, you also do all the initialization you need. No need for a separate Init method. In fact, separating creation and initialization is usually bad practice, as it leaves the object in an invalid state until Init is called.

Technically, yes, if you pass a Send function in, you could do it through initialization, however, initialization functions aren't always used, and also discouraged where possible generally in the Go ecosystem (i.e. zero value having meaning). Not saying they shouldn't be used at all (and they're used a lot with bubbletea), but if Init() is discouraged, so should initialization functions like New().

More specifically on this:

In fact, separating creation and initialization is usually bad practice, as it leaves the object in an invalid state until Init is called.

Same thing if someone doesn't call the initialization function. It's just a slightly different way of doing effectively the same thing. There is also a huge difference between initializing something and "starting" something. Even in the Go ecosystem, it's common to have the "starting" of something (e.g. a server) be a separate method, so you can prepare something before you actually start using it.

There are also a few problems with just the initializer actually "starting" the state effectively for a model. Sometimes you want to instantiate the model without running init until the model is actually used. The example I provided is a perfect usecase -- if the instantiation function sends that command, but that model isn't designed to be used yet (e.g. gets enabled depending on something else happening), it means that the command may get lost/not sent back to the child model, and thus that model never properly initializes. And because of problems like that, it will 100% lead devs to just updating the state directly asynchronously.

On Update, if the msg for the "Submit" button press is received, I can start each request on its on goroutine, and update the model to represent the in-flight requests. As the responses are received, they can Send a message of response received, which will trigger the Update call to handle it.

You could imagine a variation where the requests are sent on a regular basis from the start. In that case I could just start a goroutine when the program starts that sends a message on a timer to trigger the request.

There's no Command and Init in this implementation, which, in my opinion, makes it easier to understand. But perhaps I'm missing something.

What you're suggesting, from my experience, would lead to bad practices too easily from folks who aren't as familiar with the codebase, primarily around isolating where state is updated, though there are a lot of other gotchas. In the abstract, it would definitely be easier, but also easier to footgun.

For context: The bigger the interface, the weaker the abstraction.

That doesn't mean one should always strive for the tiniest of interfaces to the point where they're hiding what is happening from the consumer of the thing being used, which the suggested approach would, I think, obfuscate what is happening. With bubbletea v2, the interfaces for bubbletea are even smaller, containing just 2 methods (and 2 additional interfaces covering different methods for rendering).

---

I do think there is a possible middle ground that makes more complex asynchronous stuff easier, without breaking out of the ELM architecture, but definitely would need a lot of brainstorming.