Scenario with several views

[andmart]

Hey,

I loved the lib and I am considering it to one project, but one thing is not clear to me.

Based on Views example where the solution was to create subviews to change the view, if we have several views won't be extreme complex to keep the logic and state in the same place?
Is there a way to change or push a new model to the program in a way that we can encapsulate the logic for this view?

[eduardoagarcia]

A rough answer: in a model, you can have one or more sub-models rendered within the primary model. You can keep track of which view is displayed (or active) based on various state variables in the primary model. From there, you can use the same logic to send events and messages (or not) to the sub-models, as well as render those sub-models.

I create "screens" (or sub-models) that my primary app displays based on logic in my app. These screens can be separate go files, each with its own model definition.

In the Update method of your primary app, you can logically pass the app cmd(s) to your sub-models via the <submodel>.Update(cmd) method based on what screen is active based on your state variables.

In the View method of your primary app, you can logically render your sub-models via the <submodel>.View() method, also based on what screen is active.

I might have a variable called menuActive in my main app. And when menuActive == true I call menu.Update(cmd) as well as menu.View() to render the menu. You can then do things like listen for events, and when a keypress of esc happens (or whatever), you can set menuActive = false and now your logic takes over and menu is no longer visible and won't respond to other cmd events.

Hopefully this generalized overview helps you get started 🙏