feat(ev-dev): part 5 – add interactive TUI dashboard

[randygrok]

Description

Adds an interactive terminal UI dashboard to ev-dev with the --tui flag. The TUI displays real-time blocks, logs, and accounts panels using ratatui, with a custom tracing layer that captures log events in real-time. Plain log output remains the default behavior.

Type of Change

• New feature (non-breaking change which adds functionality)

Testing

• TUI renders blocks, logs, and accounts panels
• Keyboard navigation works (Tab, arrows, q to quit)
• Terminal properly restored on exit or panic
• Plain log output mode (--tui off) unchanged

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 81f88a58-c595-4496-ab62-6a7ecca77a1d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/ev-dev-part5-tui

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Claude finished @randygrok's task —— View job

---

Code Review for TUI Dashboard Feature

I've completed a thorough review of the TUI dashboard implementation for ev-dev. This is a well-structured feature that adds significant value to the development experience. Here's my comprehensive feedback:

✅ Strengths

Architecture & Design:

• Clean separation of concerns with a well-organized module structure (tui/)
• Proper async architecture using tokio channels for communication
• Smart tracing integration that hooks into reth's logging system
• Good use of the RAII pattern with TerminalGuard for cleanup

Code Quality:

• Consistent error handling with eyre::Result
• Well-structured data models (LogEntry, BlockInfo, TxInfo)
• Proper use of Rust idioms (const fn, pattern matching)
• Good naming conventions and clear separation of UI logic

🔍 Areas for Improvement

1. Performance Considerations

• Memory Management: The balance poller in app.rs:334 creates a new HTTP provider on every 2-second interval, which could lead to connection leaks. Consider reusing the provider:

  // Current approach creates new provider each time
  let provider = ProviderBuilder::new().connect_http(rpc_url.parse().expect("valid RPC URL"));

  Recommendation: Create provider once and reuse it.

• Buffer Limits: Fixed limits of MAX_LOGS: 1000 and MAX_BLOCKS: 200 are good, but consider making them configurable for different use cases.

2. Error Handling

• Silent Failures: In tracing_layer.rs:81, failed log sends are silently ignored with let _ = self.tx.try_send(entry);. This could mask important issues.
• RPC Errors: Balance fetching failures only show "? ETH" without any user indication that there's a connectivity issue.
• Resource Management: The balance poller spawns an infinite loop without proper cancellation handling.

3. Security Concerns

• Clipboard Access: The arboard dependency accesses system clipboard which could be a security consideration in some environments. This is properly isolated to specific key presses, which is good.
• Private Key Handling: Private keys are stored in memory and accessible via clipboard copy. While this is expected for a dev tool, it's worth noting.

4. UI/UX Issues

• Overflow Handling: In ui.rs:297, block detail popup uses fixed percentages (80%, 60%) which might not work well on very small terminals.
• Scrolling Logic: The blocks panel scrolling calculation in ui.rs:136-140 could potentially cause index out-of-bounds if block_selected gets corrupted.
• No Loading States: No visual indication when fetching block details or waiting for RPC responses.

🔧 Specific Issues Found

1. Potential Race Condition (main.rs:380):

tui::spawn_balance_poller(rpc_url, accounts, balance_tx);
tui::run(app).await?;

The balance poller starts before ensuring the RPC server is actually ready, which could cause early failures.

2. String Truncation Logic (app.rs:296-302):
The truncate_hex function assumes strings are longer than 10 characters for truncation, but doesn't validate hex format.

3. Channel Buffer Sizing (main.rs:317, app.rs:90):
Different buffer sizes (10,000 for logs vs 16 for balances) seem arbitrary and could cause backpressure issues.

🎯 Recommendations

High Priority:

1. Fix Resource Leaks: Reuse HTTP providers in balance polling
2. Add Cancellation: Properly cancel background tasks when TUI exits
3. Improve Error Visibility: Show connection status in TUI when RPC fails

Medium Priority:
4. Add Terminal Size Checks: Validate minimum terminal dimensions before starting TUI
5. Implement Loading States: Show when fetching block details
6. Add Configuration: Make buffer sizes and polling intervals configurable

Low Priority:
7. Add Tests: The TUI components would benefit from unit tests
8. Enhanced Keyboard Shortcuts: Consider adding more navigation options

📊 Dependencies Review

The new dependencies are appropriate and well-chosen:

• ratatui 0.30: Modern, actively maintained TUI framework
• crossterm 0.29: Cross-platform terminal handling
• arboard 3: Reasonable choice for clipboard access
• All dependencies use reasonable version constraints

🛡️ Security Assessment

✅ Low Risk:

• Clipboard access is user-initiated
• Private keys are only for development
• Network calls are to localhost

⚠️ Consider:

• Add flag to disable clipboard functionality if needed
• Document security implications in README

🧪 Test Coverage

Missing Tests:

• TUI event handling logic
• Log parsing and block info extraction
• Balance formatting functions
• Terminal restoration on panic

Existing Coverage:

• The integration appears to work well with the existing reth infrastructure

📈 Overall Assessment

This is a solid implementation that significantly enhances the developer experience. The code quality is good, the architecture is sound, and it follows Rust best practices. The main concerns are around resource management and error handling, which are common in async TUI applications.

Rating: 8.5/10 - Well-implemented feature with some room for polish

The TUI functionality works as described and provides real value. The integration with the existing codebase is clean and doesn't introduce breaking changes. With the recommended improvements, this would be an excellent addition to the project.

---