Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Jul 27, 2025

This PR addresses the feedback from @mrubens on PR #5996.

Summary

Instead of creating a new checkpoint after each message, this change shows the same checkpoint button on all subsequent messages from the point the checkpoint was created. This is a UI-only change as requested.

Changes

  • Modified ChatView to track the last checkpoint info
  • Updated ChatRow to display checkpoint UI on all messages after a checkpoint
  • Created ChatRowWithCheckpoint wrapper component to handle checkpoint display logic
  • Removed rendering of checkpoint_saved messages themselves

Benefits

  • Cleaner UI with less repetitive checkpoint messages
  • Users can still access checkpoint functionality from any message after a checkpoint is created
  • No backend changes required - purely a UI improvement

Fixes the issue raised in #5996 (comment)


Important

UI updated to show checkpoint button on all messages after a checkpoint, using ChatRowWithCheckpoint component.

  • UI Behavior:
    • ChatRow now uses ChatRowWithCheckpoint to display checkpoint UI on all messages after a checkpoint.
    • ChatRowContent no longer renders checkpoint_saved messages.
    • ChatRowWithCheckpoint component handles logic for displaying checkpoint UI.
  • State Management:
    • ChatView tracks lastCheckpointInfo using useMemo to optimize recalculation.
    • lastCheckpointInfo passed to ChatRow for rendering checkpoint UI.
  • Components:
    • ChatRowWithCheckpoint introduced to wrap ChatRowContent and manage checkpoint display logic.

This description was created by Ellipsis for ee6f074. You can customize this summary. It will automatically update as commits are pushed.

…eating new checkpoints

- Modified ChatView to track the last checkpoint info
- Updated ChatRow to display checkpoint UI on all messages after a checkpoint
- Created ChatRowWithCheckpoint wrapper component to handle checkpoint display logic
- Removed rendering of checkpoint_saved messages themselves

This change improves the UI by showing a persistent checkpoint button on all messages after a checkpoint is created, rather than creating new checkpoint messages after each interaction.
@roomote roomote bot requested review from cte, jr and mrubens as code owners July 27, 2025 14:02
@dosubot dosubot bot added size:M This PR changes 30-99 lines, ignoring generated files. UI/UX UI/UX related or focused labels Jul 27, 2025
@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Jul 27, 2025
@daniel-lxs daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Jul 29, 2025
@hannesrudolph hannesrudolph added PR - Needs Preliminary Review and removed Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. labels Jul 29, 2025
Copy link
Member

@daniel-lxs daniel-lxs left a comment

Choose a reason for hiding this comment

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

Review

onBatchFileResponse,
isFollowUpAnswered,
editable,
lastCheckpointInfo: _lastCheckpointInfo,
Copy link
Member

Choose a reason for hiding this comment

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

Is this intentional? The parameter is prefixed with underscore indicating it's unused, but it's still part of the component's props interface. Since explicitly passes for this parameter, could we remove it entirely from to avoid confusion?

}

// Default return for messages that don't match any case
return null
Copy link
Member

Choose a reason for hiding this comment

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

This return statement appears to be unreachable. The switch statement above should handle all cases, and if it doesn't, TypeScript would typically catch this. Could we either remove this unreachable code or add a proper default case to the switch statement if there are actually unhandled message types?

}, [messages])

// Track the last checkpoint message
const lastCheckpointInfo = useMemo(() => {
Copy link
Member

Choose a reason for hiding this comment

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

Performance consideration: This recalculates on every render when any message changes. Since checkpoint messages are relatively rare, could we optimize this by only recalculating when messages with are added? Perhaps we could track the last checkpoint info in a ref and only update it when needed?

@daniel-lxs
Copy link
Member

@roomote-agent Address the review I just left, commit to this PR, do not create a new one

@daniel-lxs daniel-lxs moved this from PR [Needs Prelim Review] to PR [Changes Requested] in Roo Code Roadmap Jul 29, 2025
@roomote
Copy link
Contributor Author

roomote bot commented Jul 29, 2025

👋 I've seen your review feedback and will address the following issues:

  1. Remove the unused parameter from
  2. Remove the unreachable statement
  3. Optimize the performance for calculation

Working on these changes now and will commit to this PR branch.

- Remove unused lastCheckpointInfo parameter from ChatRowContent
- Remove unreachable return null statement
- Optimize useMemo performance for lastCheckpointInfo calculation
@roomote
Copy link
Contributor Author

roomote bot commented Jul 30, 2025

Review feedback addressed

I've successfully addressed all the issues you raised in your review:

Changes Made

  1. Removed unused parameter from component

    • The parameter was prefixed with underscore indicating it was unused
    • Removed it from the props interface and function signature
    • Updated to no longer pass this parameter
  2. Removed unreachable statement

    • The statement at the end of was unreachable due to the switch statement handling all cases
    • Cleaned up the code by removing this dead code
  3. Optimized performance for calculation

    • Split the logic into two separate hooks to avoid complex expressions in dependency arrays
    • First filters checkpoint messages from all messages
    • Second calculates the last checkpoint info only when checkpoint messages change
    • This ensures the expensive filtering only happens when necessary

Testing

  • ✅ All tests pass (76 test files, 838 tests passed)
  • ✅ ESLint checks pass with no warnings
  • ✅ TypeScript compilation successful
  • 🔄 CI checks are currently running

The changes maintain the same functionality while addressing the code quality concerns you identified.

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

Labels

PR - Changes Requested size:M This PR changes 30-99 lines, ignoring generated files. UI/UX UI/UX related or focused

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants