High Level Architecture

[sdd]

I think the initial architecture that we have has a couple of shortcomings and after having looked at a few other projects for inspiration and thought about it a bit more, I'm proposing something more like this. I'm still not 100% on it - I'll outline the failings of this approach below.

Current Approach

graph TD
    C[App Task] -->|TanicMessage| D[UI Task]
    E([Terminal Events]) ----> D
    D -->|TanicMessage| C

Loading

Summary

• The App And UI Tasks both manage their own state and communicate by sending a TanicMessage to each other.
• User input from and events from crossterm are processed by the UI Task. Some of those will only update the UI State (eg moving between different items in the treeview), Some will result in a TanicMessage being sent to the AppTask (eg selecting a namespace), and some will result in both (pressing Q to quit).

Disadvantages

• Two-way data flow with separate state can be considered a bit of an anti-pattern in the UI world
• OS signals not handled properly
• Two sets of state

Proposal 1

graph TD
    A([OS Signals]) --> B[Lifecycle Mgr]
    B -->|Actions| C[App State Mgr]
    C -->|State| D[UI Mgr]
    E([Terminal Events]) ----> D
    D -->|Actions| C

Loading

Summary

• All state management happens in the AppStateMgr in a manner similar to redux in the UI world. One-way data flow is easier to reason about and simpler to test
• Actions are sent to the AppStateMgr that modify the state.
• The UI is stateless, taking in a reference to a State and reproducibly rendering the same thing each time for a given state.
• The UI translates terminal events into application specific actions that it dispatches to the AppStateMgr.
• Separate Lifecycle Manager for listening for OS signals and dispatching exit actions.

Advantages

• One-way data flow is easier to reason about and simpler to test
• Stateless UI is easier to reason about and simpler to test
• More familiar design pattern to anyone who has worked on web front ends

Disadvantages

• UI coupled to app state.
• app state needs to track minutiae of UI state (what text is currently in a text box being edited, which item in a list is the one that the user has moved focus to, etc)

Proposal 2

graph TD
    A([OS Signals]) --> B[Lifecycle Mgr]
    B -->|Actions| C[App State Mgr]
    C -->|State| D[UI]
    E([Terminal Events]) ----> D
    D -->|Actions| C
    C -->|State| F[Iceberg Mgr]
    F -->|Actions| C

Loading

Summary

• Similar to proposal 1 but with Iceberg-specific behaviour moved into its own IcebergMgr that subscribes to State and dispatches actions in the same way as the UI does.

Advantages

• Permits less coupling between UI and Iceberg-specific state as some of the internal iceberg state can stay within the Iceberg mgr rather than being exposed as part of the application state
• Iceberg Mgr may be more re-usable in another tanic application that perhaps has another UI, as it is decoupled from having its state co-mingled with the UI state