Replies: 4 comments
-
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:/lrstanley/bubblezone/blob/master/examples/full-lipgloss/main.go Basically:
and
Hopefully I can figure out how to run and test the components individually when structuring it this way. |
Beta Was this translation helpful? Give feedback.
-
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, |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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
However, inside
myCustomBubbleteaMiddleware
when building theteaHandler
(to use the variable name fromexamples/bubbleteaprogram
) I don't have access to thessh.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.
Beta Was this translation helpful? Give feedback.
All reactions