pointer receivers for tea.Model's

[notjedi]

i was wondering why all tea.Model's have their Init, Update and View methods as value receivers instead of pointer receivers (which leads to returning the tea.Model after each call to Update). any particular reason behind this design choice?

PS: sorry if i've not spotted any obvious reasons.

[bashbunni]

I believe it's due to the functional roots from the Elm Architecture where immutability is preferred. Personally I will have functions that use pointer receivers in a tea.Cmd if they need to modify the state of the model before the next render 🤷

[stschindler]

I'm quite new to Go, so I'm curious about this a little bit more: If we have a value receiver, and return again a value, will that effectively result in 2 copies? I can imagine that the compiler optimizes this, but optimizations can never be guaranteed.

[ogios]

but it also works with pointers, thus i'm curious about the thoughts behind this

[matta]

I wondered about this as well, until I learned more about both Go and Bubbletea and realized two things:

1. It is not required to write a model's Init/Update/View methods using value receivers. This happens to be how all the Bubbletea examples are written, but Go allows programs to write it as func (m* myModel) Init() tea.Cmd {...} and it will still satisfy the interface.
2. As a separate issue, Update returns a tea.Model, which is an interface type.

In all but the most trivial examples, I find it clearer to satisfy tea.Model by taking pointer receivers. Most of the time these models have many other methods that need to take pointer receivers. I think it is generally well accepted that:

1. As a general guideline, prefer to make the methods for a type either all pointer methods or all value methods.
2. When in doubt, use a pointer receiver.
3. If the receiver is a “large” struct or array, a pointer receiver may be more efficient. (and many of my models tend to grow in size over time as the app evolves)

More on all that at https://google.github.io/styleguide/go/decisions#receiver-type

I think of the the tea.Model return from Update as a separate thing. This could be useful for entering entirely new program states that are represented by different model types. E.g. switching top level screens, progressing to a different phase of a program, etc. I've yet to see this actually used this way. For example, all bubbletea examples just return the same model every time. So, this amounts to boilerplate in most cases. If I were to rewrite history and design Bubbletea from the beginning myself, I'd probably eliminate the tea.Model return value. Programs that need that could instead create a meta-Model struct themselves, and store the "current" model in a single field of that model. In practice, this is what the more complex Bubbletea apps do in practice anyway (they have state in one fat model and dispatch from there).

[GeertJohan]

I'm a long time Go programmer but have only been using bubbletea for a little while now, it's pretty cool to write nice UI's with Go! Who needs Flutter when you can write TUIs!? 😀

However, this is one of the things in bubbletea that frustrates me a little bit. The design feels inconsistent as there are two ways of writing and using .Update(..). Some models such as bubbles/progress.Model return the tea.Model interface, where other models such as bubbles/table.Model return their own struct type.
So for bubbles/progress, m.myProgress, cmd = m.myProgress.Update(msg) won't compile, but for bubbles/table it's actually necessary to m.table, cmd = m.table.Update(msg) for it to function correctly.
This is then further confused by the table.Model having pointer receivers on methods such as .SetWidth(..) where you don't have to overwrite the model at the caller.

Take for example:

func (m myModel) Update(msg tea.Msg) (myModel, tea.Cmd) {
	switch msg := msg.(type) {
	case someThing:
		m.answer = 42 // seems ineffective, linters will warn about this. (1)
		m.table.SetWidth(10) // fine to do
	}

	var cmd tea.Cmd
	m.table, cmd = m.table.Update(msg) // not idiomatic Go? (2)
	return m, cmd
}

1. Updating fields on the by-value received mModel are ineffective unless it is returned and overwritten at the parent. The revive linter has a rule for this.

2. Updating a value with the return value of a method that was called on the same value does not feel like idiomatic Go. Method receivers are usually expected to update their receiver.

I think it would be best if the tea.Model return value would be dropped from Update(), and pointer receivers used for all models. I understand that changing this will be breaking, but the migration is fairly straightforward. It changes the framework to a single way of writing and using .Update(..), which will make the code easier to understand and less error prone. Having a breaking change is still fine since bubbletea is 0.x.

Resulting example:

func (m *myModel) Update(msg tea.Msg) (tea.Cmd) {
	switch msg := msg.(type) {
	case someThing:
		m.answer = 42
		m.table.SetWidth(10)
	}

	cmd := m.table.Update(msg)
	return  cmd
}

[randomvlad]

Having a breaking change is still fine since bubbletea is 0.x.

Bubbletea is on v2 "now" and this discrepancy is still around. Bummer. Wish the main docs would at least mention the considerations and implications of pointer vs value tea.Model receivers.

I have not looked under the hood, but got a paranoid suspicion there may be some hidden gotchas to pointer models as it pertains to multi-threading and race conditions. However, pointer receivers for all models feels the way to go.

[ghostsquad]

this has been a point of confusion for me as well. The moment you introduce a map into your model state, you have to do a lot more work to ensure that your model is immutable (as maps are pointers by default), is it even worth the effort?

[meowgorithm]

Generally, no. The immutability is more of a starting place, but things like pointers and maps are generally fine in Bubble Tea, however you should still only change state in Update.