If you are interested in a more object oriented approach to organizing TUIs, you can use a
Component based approach.
A couple of projects in the wild use this approach
We also have an
component template that has an example of this
Component based approach:
We already covered TEA in the previous section. The
architecture takes a slightly more object oriented trait based approach.
Each component encapsulates its own state, event handlers, and rendering logic.
Component Initialization (
init) - This is where a component can set up any initial state or resources it needs. It’s a separate process from handling events or rendering.
Event Handling (
handle_mouse_events) - Each component has its own event handlers. This allows for a finer-grained approach to event handling, with each component only dealing with the events it’s interested in. This contrasts with Elm’s single update function that handles messages for the entire application.
State Update (
update) - Components can have their own local state and can update it in response to actions. This state is private to the component, which differs from Elm’s global model.
render) - Each component defines its own rendering logic. It knows how to draw itself, given a rendering context. This is similar to Elm’s view function but on a component-by-component basis.
Here’s an example of the
Component trait implementation you might use:
One advantage of this approach is that it incentivizes co-locating the
render functions on a component level.