(v2) Is Bubbletea 2 going back to Init() (tea.Cmd)?

[tuxtlequino]

I had been working on your alpha version. In the notes, it was noted in the alpha release notes that one of the changes was to move from Init() (tea.Cmd) to Init()(tea.Model, tea.Cmd). But today I decided to move forward to the razor's edge and use the latest alpha version of bubble tea and I can see that the developers moved back to Init() (tea.Cmd) which although now breaks all of my code, it is perfectly fine. I understand that I am experimenting with alpha code and some of those changes are to be expected. I just wanted to know if that is a change that you are planning to move forward? If you are gracious enough and you find it that since you are already reading this, could you explain some of the logic or reasons behind this change? Just for curiosity and to expand my knowledge of bubbletea.

Again, thank you or all you do. Looking forward to your answer.

[meowgorithm]

We are so flattered you're not only trying v2, but bleeding edge v2-exp to boot!

In short, yes, we've settled on Init() tea.Cmd. After trying many different API shapes we've decided that's still the best way to do things, as one still has to initialize the model when passing it to the Program as an argument, which becomes a bit redundant with Init() (tea.Model, tea.Cmd):

type model int

func (m model) Init() (tea.Model, tea.Cmd) {
    m = 5 // we can initialize the model here
    return m, nil
}

p := tea.NewProgram(model(5)) // but we can also do it here

In theory, it would be nice to specify the type and eliminate the argument with generics, à la:

p := tea.NewProgram[model]()

…but there's not way to enforce tea.Model as a constraint on model. Thus we're back where we started with Init() tea.Cmd.

Look for a new release soon, and let us know if you have any more questions!

[tuxtlequino]

Thank you very much for the answer. I can see why you are moving in that direction. I have converted most of my code to the v2 and it is working flawlessly. That is not to say that I find a lot of things irritating (specially the bubble list and how I need to propagate the resizing across my models) but that is not a v2 issue. Again, thank you for the time,

[yhcote]

@meowgorithm Thanks for the update. I must admit that I liked the idea of adding the model as a return value. Your explanation for a trivial case like p := tea.NewProgram(model(5)), make sense. Although I have been in situations where creating a new model from parameters can also benefit from an Init() routine able to returned a modified model.

I think that a New() routine, returning a newly created model, benefits from returning quickly while avoiding steps that may cause failures. Mostly that translates into creating the new model and setting model fields to values from defaults or options. Init() would then be used to encapsulate neatly calls to initialization routines to prepare the model. In some cases, those initialization routines may update different fields from the newly created model and would have the ability to return the updated model.

Without this ability, initializing complex applications will have to be done in the Update() section, which devalues the use of the model's Init() routine. In fact, it's not rare to see bubble tea applications simply returning 'nil' there.

That being said, I don't think it's a showstopper either. Just some thoughts.