[ 
https://issues.apache.org/jira/browse/CAMEL-23573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-23573.
---------------------------------
    Resolution: Fixed

> camel-tui - Refactor CamelMonitor into per-tab classes
> ------------------------------------------------------
>
>                 Key: CAMEL-23573
>                 URL: https://issues.apache.org/jira/browse/CAMEL-23573
>             Project: Camel
>          Issue Type: Task
>          Components: camel-jbang
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.21.0
>
>
> CamelMonitor.java has grown to ~6,800 lines with ~130 fields and ~124 methods 
> across 9 tabs. All tab state, event handling, rendering, and data logic lives 
> in a single class. This makes it increasingly difficult to add new features 
> and causes merge conflicts when working on different tabs in parallel.
> Refactor by extracting each tab into its own class implementing a common 
> {{MonitorTab}} interface:
> - {{handleEvent(KeyEvent)}} — tab-specific key handling
> - {{render(Frame, Rect)}} — tab content rendering
> - {{renderFooter(List<Span>)}} — footer hint rendering
> Shared state ({{selectedPid}}, {{data}}, {{tabsState}}, etc.) moves to a 
> {{MonitorContext}} object passed to each tab.
> *Extraction by complexity (recommended order):*
> # Health (~100 lines, 2 fields, 2 methods) — trivial
> # Consumers (~150 lines, 4 fields, 6 methods) — simple
> # Circuit Breaker (~400 lines, 7 fields, 7 methods) — moderate
> # Endpoints (~400 lines, 15 fields, 6 methods) — moderate
> # Overview (~350 lines, 5 fields, 8 methods) — moderate
> # HTTP (~500 lines, 8 fields, 10 methods) — moderate
> # Log (~250 lines, 17 fields, 5 methods) — moderate
> # Routes (~1,200 lines, 25+ fields, 20+ methods) — complex
> # History (~900 lines, 20+ fields, 15+ methods) — complex
> After refactoring, CamelMonitor.java shrinks to ~1,500 lines containing: CLI 
> setup, main layout rendering, global event dispatch, data refresh/parsing, 
> inner data classes, and tab registration.
> *Benefits:*
> - Each tab is a self-contained file (100-1,200 lines)
> - Parallel development on different tabs without merge conflicts
> - Adding new tabs = one new file + one registration line
> - {{handleEvent()}} drops from 590 to ~50 lines (dispatch only)
> - {{renderFooter()}} drops from 165 to ~10 lines (delegates to active tab)
> *Inner data classes* (IntegrationInfo, RouteInfo, ProcessorInfo, etc.) should 
> also be extracted to separate files as part of this refactoring.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to