Components don't implement tea.Model

[ghostsquad]

I've been doing a bit of research on bubbles and various of applications that use it, and in almost all cases, including in Bubbles itself, the tea.Model interface is seldom actually followed. I believe the reason for this is that when running Update, parent components want (without a type assertion) to have all the other methods on the model.

The problem with this (and I'll provide some examples below), is that it means the tea.Model interface is almost entirely useless except for the very top-level app component. However, if the abstraction could be followed more closely it would allow more components to be composed together.

Here's a concrete example of a component that doesn't implement tea.Model, and possible solutions

bubbles/viewport/viewport.go

Line 266 in cd2593c

func (m Model) Update(msg tea.Msg) (Model, tea.Cmd) {

Here's a synopsis of the methods that are needed to "control" or "inspect the state of" a viewport:

// inspects state
func (m Model) AtTop() bool
func (m Model) AtBottom() bool
func (m Model) PastBottom() bool
func (m Model) ScrollPercent() float64

// controls behavior
func (m *Model) SetContent(s string)
func (m *Model) SetYOffset(n int)
func (m *Model) ViewDown() []string
func (m *Model) ViewUp() []string 
func (m *Model) HalfViewDown() (lines []string)
func (m *Model) HalfViewUp() (lines []string)
func (m *Model) LineDown(n int) (lines []string)
func (m *Model) LineUp(n int) (lines []string)
func (m *Model) GotoTop() (lines []string) 
func (m *Model) GotoBottom() (lines []string)

The control methods could be made private, with an associated public tea.Msg.

The inspect methods could be implemented as callbacks within the constructor. Example:

type Model struct {
   AtTop func()
}

type ModelOptions struct {
    AtTop func()
}

type ModelOption func(options *ModelOptions)

func New(options ...ModelOption) Model {
   opts := &ModelOptions{
      AtTop: func(){}
   }
   for _, o := range options {
      o(opts)
   }
   
   return Model{
      AtTop: opts.AtTop
   }
}

Though, this means that this might necessitate some design changes, as these don't return a bool instead they are called when the viewport is at the top. Thus, anyone using this cannot "ask" for the viewports state, instead, they must simply listen for when the state changes.

I'm opening this as a discussion because I'm a new user to bubbletea and bubbles, and I found this to be an interesting discovery.

[bashbunni]

Hey @ghostsquad, just wanted to chime in here. The bubbles don't implement the tea.Model interface as it led to a lot of type assertions to update these components. I commented on an open PR with more details on this, but TLDR: it's a WIP that we are actively working on right now.
#492 (comment)

I hope this helps to clarify! (That link has more details)