(v2) Composing tea.Models

[GeenDutchman]

Hello! I am updating a project that uses tea/lipgloss etc. (tea @ v2.0.0-beta.6 and lipgloss @ v2.0.0-beta.3 and bubbles @ v2.0.0-beta.1.0....).

I might have an incorrect paradigm, but I have a tea.Model that is composed of two other tea.Models. I am intending on showing one on the left, and the other on the right. (Left shows a tree a la charmbracelet/bubbles#639 charmbracelet/lipgloss#446 , and right shows the details of the selected tree item). The Right model starts as nil.

With both of them returning the new tea.View and its Layer attribute, how can I display these side by side? The Layer has no real way to retrieve the contents so I can join them vertically using lipgloss. Add in some confusion that both lipgloss and tea have a Layer object but they are not interoperable, and you have my current situation.

For now I'll probably move implementation from the Right model into my central model until I get further coaching here. That said, I await when 2.0.0 is out on all 3 libraries!

[lrstanley]

Couple of things:

• tea.Layer is an interface which represents something which can be rendered onto a screen -- it's abstract for high-performance usecases.
• lipgloss.Layer is designed to be used with lipgloss.NewCanvas(), which creates multi-layer layouts using multiple lipgloss.Layer's, stacked on top of each other, side by side, etc. lipgloss.Canvas implements tea.Layer.

With the new tea.View functionality (and tea.Model being updated to use tea.View), the idea now is that this is for the root model only. You can decide on how your children components should be rendered, but it probably shouldn't be through tea.View/tea.Model, because it has a bunch of stuff that components should probably never implement (controlling alt screen, window title, etc).

Suggestions:

1. root model uses View() tea.View (implementing tea.Model), and children use View() string still, and you can use view.SetContent(lipgloss.JoinVertical(children...)) to set the content of the root. I.e., children should no longer try and satisfy tea.Model. Because this is using text joining, you don't necessarily need to think about offsets, like before.
2. root model uses View() tea.View (implementing tea.Model), and children use View() *lipgloss.Layer, and in your root, you set view.Content to lipgloss.NewCanvas(children...). For a split layout, from the root, you'd set the offset on the 2nd view to be 50% of the X direction, for horizontal splitting, for example. Each layer is independent of one another, which means if you don't set the offset of the 2nd/right component, it will be rendered on top of the 1st component, if that makes sense.

For an example of 2 (not quite exactly the same, but gets the idea across), see https://github.com/charmbracelet/bubbletea/blob/v2-exp/examples/canvas/main.go

Also worth noting that lipgloss.Canvas supports Render() string, so you could also do a mix of both, if you wanted to.

[GeenDutchman]

Ooh, I thought it was a paradigm issue! Okay, good to know. This would be a good candidate for when they update the documentation for 2.0.0.

So, the Program runs a tea.Model. tea.Model presents a tea.View. Children of that tea.Model should likely not be tea.Models. Interestingly, a tea.Model can return a totally different tea.Model on Update(msg).
So maybe I should define some BubbleModel interface or something with returning a string or lipgloss layer for View() (also with an Update(msg) and Init()). I can see doing a lipgloss.Layer because that can encapsulate more information, but yeah, either should work.

[GeenDutchman]

Very quickly ran into the fact that a BubbleModel should not return a tea.Model on Update lol.

type BubbleModel interface {
    Init() tea.Cmd
    Update(tea.Msg) (BubbleModel, tea.Cmd)
    View() string // not sure if lipgloss.Layer is the right move here
}

[GeenDutchman]

Nope, nope, wrong way, still learning!

[lrstanley]

It's worth noting as well that child components also doesn't necessarily need to adhere to Update(tea.Msg) (SomeModel, tea.Cmd) either. It does more closely follow the ELM architecture, but I often find myself doing the following in my projects: Update() tea.Cmd, and just keeping a pointer to the component in the parent component, as it's rare to actually need to completely replace a component with a completely different component. If I do need to dynamically swap components, I do an interface similar to what you have:

type Model interface {
	Init() tea.Cmd
	Update() tea.Cmd
	View() string // Or if you have a usecase for advanced layering logic, *lipgloss.Layer
}

Another idea I'll throw out, is you could do a generics version, which still allows returning a non-pointer in update to keep ELM architecture:

type Model[T any] interface {
	Init() tea.Cmd
	Update() (Model[T], tea.Cmd)
	View() string
}

And in your parent components:

type MyModel struct {
	ChildOne Model[SomeComponent]
	ChildTwo Model[SomeOtherComponent]
}

// [...]