fix n+1 api-requests on admin/checklist

[pmattmann]

resolves #7635

[github-actions]

⛔ Feature branch deployment currently inactive.

If the PR is still open, you can add the deploy! label to this PR to trigger a feature branch deployment.

[BacLuc]

hmm, does not seem to help much:
https://dev.ecamp3.ch/camps/5d28f99890bc/Basiskurs-Wolfsstufe-2025/admin/checklist/ebbd0c61eb85/Ausbildungsziele

https://pr7641.ecamp3.ch/camps/5d28f99890bc/Basiskurs-Wolfsstufe-2025/admin/checklist/ebbd0c61eb85/Ausbildungsziele

[BacLuc]

@CodeRabbit review this pr

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll help you review this PR! Let me gather the necessary information about the changes first.

---

🏁 Script executed:

#!/bin/bash
# Get PR information including title, description, and files changed
gh pr view 7641 --json title,body,files,additions,deletions,changedFiles

# Get the diff for this PR
gh pr diff 7641

Length of output: 3150

---

@BacLuc Here's my review of PR #7641:

✅ Overall Assessment: Good Performance Fix

This PR effectively addresses the N+1 API request problem by refactoring the activitiesWithChecklistItem computed property into a more efficient async watcher pattern.

Strengths:

1. 🚀 Performance Improvement: Eliminates the N+1 API calls that were happening every time the computed property was accessed
2. ⚡ Efficient Async Handling: Uses Promise.all to run API calls concurrently rather than sequentially
3. 🎯 Smart Reactivity: Only recalculates when checklistItem changes, not on every access
4. 📊 Better API Usage: Uses $href() method for URI resolution, which is likely more efficient than the previous approach

Areas for Enhancement:

1. Error Handling: Consider adding try-catch blocks around the async operations:

async handler(checklistItem) {
  try {
    await this.camp.activities()._meta.load
    // ... rest of the logic
    this.activitiesWithChecklistItem = res
  } catch (error) {
    console.error('Error loading activities with checklist item:', error)
    this.activitiesWithChecklistItem = []
  }
}

2. Loading State: Consider adding a loading indicator while the async operations are running:

data() {
  return {
    entityProperties: ['checklist', 'text'],
    entityUri: '',
    activitiesWithChecklistItem: [],
    isLoadingActivities: false,
  }
}

3. Race Condition Protection: If checklistItem changes rapidly, consider debouncing or using a request ID to prevent stale data:

async handler(checklistItem) {
  const requestId = Date.now()
  this.currentRequestId = requestId
  
  // ... async operations ...
  
  if (this.currentRequestId === requestId) {
    this.activitiesWithChecklistItem = res
  }
}

Technical Notes:

• The refactoring from computed to watcher + data is appropriate for this async scenario
• The immediate: true option ensures the data loads on component creation
• The sorting logic remains unchanged, maintaining existing functionality

Conclusion:

This is a solid performance optimization that should significantly reduce API calls. The core implementation is sound, and the suggested enhancements would make it more robust for production use.

Recommendation: ✅ Approve with optional improvements for error handling and loading states.

[manuelmeister]

Approved by @pmattmann