Well, lost a day trying to update to the #charm v2 rc version library in a couple of my projects.
Today, besides a couple of questionable API changes there was a ton of mismatched dependency versions which led to compilation errors.
I need to stop trying to do this until they truly release this new version.
I managed to solve the compilation errors. These were in the end the result of incomplete migration (on my part) to the new package namespaces for the main charm libraries from github.com/charmbracelet/ -> charm.land/
However the API change from a simple View() string -> View() tea.View is quite difficult to navigate and I haven't made everything render correctly yet.
The models that *do* render have issues with cursor movement having become quite a bit more laggy than before. I haven't investigated if this is due to some missing knobs when initializing the TUI, or due to code inefficiencies. Sigh...
@mariusor in general you'll only want to use a tea.View at the top level. I think there's sort of misunderstanding that children need to implement tea.Model, which isn't true. The purpose behind tea.View is more to make things that were previously async synchronous.
For example, cursor shape and altscreen presence are parts of the view, and as commands they can come in out of sync.
@meowgorithm in my case children need to implement tea.Model because they're exported as models themselves.
It's much simpler to reason about, let's say a list of items, when the individual items are models themselves that are responsible for their own updating/rendering. This kinda expanded to having all intermediary models follow the Elm pattern, because it just felt more natural.
In conclusion, my advice for tea.View is to make it much easier to render. A "String() string" or "Render() string" method on it is a must in my opinion. It would make composition simpler, and would decrease headaches for people that implemented their models similarly to me.
marius
Christian Rocha