String together multiple tea.Programs inside one Wish application?

[erwin]

Maybe my thinking is wrong, if so, please correct me.

I would like to have two, and perhaps more tea.Programs inside of a Wish app.

For example, if public key authentication fails, I would like to fall back to an email access code base authentication, that would have a UI substantially different from the rest of my app.

I think right now my only choice is to add a case inside my func (m model) View() string and either render the access code authenticator UI or render the rest of the app.

I look into func myCustomBubbleteaMiddleware() wish.Middleware:

wish/examples/bubbleteaprogram/main.go

Line 61 in ce61721

func myCustomBubbleteaMiddleware() wish.Middleware {

However, inside myCustomBubbleteaMiddleware when building the teaHandler (to use the variable name from examples/bubbleteaprogram) I don't have access to the ssh.Session to check if I should instantiate the tea.Program for the emailed authentication code, or if the SSH key could be validated and thus the tea.Program for the rest of the app should be instantiated.

Also, even if I did succeed in initially correctly instantiate one of two teaHandlers, once that tea.Program successfully completed, I don't see any way the running teaHandler could be replaced by another teaHandler.

Ultimately I think the question is really your recommendation on organizing multi-screen tea applications, especially cases where the header/footer may be different on some screens (initial screens, graphs, final screens).

If a more complicated application could be built by combining smaller tea applications, seems like it could really simplify development, testing and maintenance.

[erwin]

It looks like the bubblezone (mouse tracking) example of structuring an app with multiple models is a good way to organize an app and is available right now:

https://github.com/lrstanley/bubblezone/blob/master/examples/full-lipgloss/main.go

Basically:

type model struct {
	height int
	width  int

	tabs    tea.Model
	dialog  tea.Model
	list1   tea.Model
	list2   tea.Model
	history tea.Model
}

and

func (m *model) propagate(msg tea.Msg) tea.Model {
	// Propagate to all children.
	m.tabs, _ = m.tabs.Update(msg)
	m.dialog, _ = m.dialog.Update(msg)
	m.list1, _ = m.list1.Update(msg)
	m.list2, _ = m.list2.Update(msg)

	if msg, ok := msg.(tea.WindowSizeMsg); ok {
		msg.Height -= m.tabs.(tabs).height + m.list1.(list).height
		m.history, _ = m.history.Update(msg)
		return m
	}

	m.history, _ = m.history.Update(msg)
	return m
}

Hopefully I can figure out how to run and test the components individually when structuring it this way.

[erwin]

test the components individually

It looks like the charmbracelet team has put a lot of working into testability for bubbletea components. There is a testing package coming to bubbletea, teatest.

charmbracelet/bubbletea#352

[caarlos0]

hey @erwin , yes, multiple models would be the way to go. AFAIK you can't have multiple tea.Programs as the same app, with out without wish.

Alternatively, you could decide which of the Programs you would like to run, and then run only that one (i.e. a middleware that sets the program name in the context or something like that), but more models seems better, IMHO.

BTW, @bashbunni created a video tutorial on nested models, which may help: https://www.youtube.com/watch?v=uJ2egAkSkjg

Feel free to check out our other videos as well: https://www.youtube.com/c/charmcli/videos

[bashbunni]

Yesss! This reminds me that I should do a video soon where we're doing true nested models and not a composable view. I.e. we return different models instead of managing state in a main model and showing all models in a single view