Skip to content

Restructure UI and command layers for single responsibility#30

Merged
avelino merged 1 commit into
mainfrom
avelino/refactoring-clear-project
Mar 15, 2026
Merged

Restructure UI and command layers for single responsibility#30
avelino merged 1 commit into
mainfrom
avelino/refactoring-clear-project

Conversation

@avelino

@avelino avelino commented Mar 15, 2026

Copy link
Copy Markdown
Owner

Large files were making the codebase hard to navigate and evolve. mcp.rs and cli.rs duplicated ~15 commands, app/mod.rs had 3300 LOC of inline tests, and ui/main_area.rs mixed data preparation, rendering, and text wrapping in a single 2000-line Widget impl.

Extracted shared SDK operations into commands.rs so MCP and CLI are thin dispatch layers. Broke the monolithic Widget render() into a RowBuilder with focused methods per visual element. Moved inline test suites to dedicated files and split the UI into visible_lines, text_wrap, row_builder, and view modules. No production file exceeds 450 LOC now.

Large files were making the codebase hard to navigate and evolve. mcp.rs and cli.rs duplicated ~15 commands, app/mod.rs had 3300 LOC of inline tests, and ui/main_area.rs mixed data preparation, rendering, and text wrapping in a single 2000-line Widget impl.

Extracted shared SDK operations into commands.rs so MCP and CLI are thin dispatch layers. Broke the monolithic Widget render() into a RowBuilder with focused methods per visual element. Moved inline test suites to dedicated files and split the UI into visible_lines, text_wrap, row_builder, and view modules. No production file exceeds 450 LOC now.

Signed-off-by: Avelino <31996+avelino@users.noreply.github.com>
@avelino avelino merged commit a496c24 into main Mar 15, 2026
3 checks passed
@avelino avelino deleted the avelino/refactoring-clear-project branch March 15, 2026 14:06
Comment thread src/ui/visible_lines.rs
Comment on lines +116 to +123
if lr.loading {
lines.push(VisibleLine::LinkedRefsSeparator);
lines.push(VisibleLine::LinkedRefsHeader {
count: 0,
collapsed: false,
block_index: *block_index,
});
} else if !lr.groups.is_empty() {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: In append_linked_refs, the block_index is not incremented when linked refs are loading, causing a block_index collision with the next navigable item and breaking selection logic.
Severity: MEDIUM

Suggested Fix

In src/ui/visible_lines.rs, add *block_index += 1; within the if lr.loading block inside the append_linked_refs function. This ensures the block index is correctly incremented for the loading header, maintaining synchronization with the navigation model.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/ui/visible_lines.rs#L116-L123

Potential issue: When linked references are in a loading state (`lr.loading == true`),
the `append_linked_refs` function renders a navigable `LinkedRefsHeader` and assigns it
a `block_index`. However, it fails to increment the `block_index` counter for this item.
Concurrently, the `linked_ref_section_count` function, which informs the navigation
model, returns 0 for the loading state because `lr.groups` is empty. This
desynchronization causes the next navigable item to be assigned the same `block_index`
as the loading header, leading to index collisions. This can result in UI artifacts like
two items appearing selected simultaneously or unexpected cursor jumps during
navigation.

Did we get this right? 👍 / 👎 to inform future reviews.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant