fix: map tileset selection not applying on dashboard

[Yeraze]

Summary

• DashboardMap TileLayer missing key: react-leaflet kept the same Leaflet instance when the tile URL prop changed, so picking a new tileset in Settings never refreshed the dashboard map. Added key={tilesetId} to force a remount.
• SettingsProvider baseUrl default '' broke save under BASE_URL deployments: GlobalSettingsPage, ReportsPage, MapAnalysisPage, PacketMonitorPage, and DashboardPage instantiate <SettingsProvider> without passing baseUrl, so POST /api/user/map-preferences hit the unprefixed path and 404'd. SettingsProvider now auto-detects the base from window.location when no prop is supplied; explicit prop callers (AppWithToast) are unaffected.

Test plan

• Verified locally on dev container behind /meshmonitor BASE_URL — switching Map Tileset in Settings now succeeds (200) and the dashboard map updates immediately on next load.
• CI build + tests
• Smoke-test other pages mounted via <SettingsProvider> (Reports, MapAnalysis, PacketMonitor) for any regression in baseUrl detection.

🤖 Generated with Claude Code

[github-actions]

Claude finished @Yeraze's task —— View job

---

Pull Request Review

Excellent work! This PR addresses two critical issues in the dashboard map functionality and BASE_URL deployments. The fixes are minimal, targeted, and well-implemented.

✅ Code Quality & Implementation

DashboardMap.tsx (Line 108):

• Perfect fix: Adding key={tilesetId} to the TileLayer component is the correct React solution for forcing re-renders when props change
• Clean approach: Leverages React's reconciliation algorithm rather than manual DOM manipulation
• Follows React best practices: Using the key prop to control component lifecycle

SettingsContext.tsx (Lines 165-177, 180):

• Smart auto-detection: The detectBaseUrlFromLocation() function correctly mirrors the logic in App.tsx and DashboardPage
• Robust path parsing: Properly handles edge cases (empty path, single segment, etc.)
• Maintains backward compatibility: Explicit baseUrl prop takes precedence over auto-detection
• Comprehensive route mapping: Covers all app routes for accurate base path detection

✅ Bug Fixes & Correctness

Map Tileset Issue:

• Root cause correctly identified: react-leaflet reuses Leaflet instances when only props change
• Solution directly addresses the problem without side effects

BASE_URL Deployment Issue:

• Correctly identified that SettingsProvider instantiated without baseUrl defaults to empty string
• The fix ensures API calls hit the correct prefixed endpoints (/meshmonitor/api/...)

✅ Performance Considerations

• Minimal performance impact: Key prop change only triggers re-render when tileset actually changes
• No unnecessary re-renders: Auto-detection only runs during SettingsProvider initialization
• Efficient path parsing: Simple string operations with no expensive computations

✅ Security Assessment

• No security concerns: Changes are purely UI-related with no authentication, input validation, or data exposure issues
• Safe string manipulation: Path parsing uses basic string methods without eval or dynamic code execution

⚠️ Minor Considerations

Test Coverage:

• Consider adding a test to verify TileLayer re-renders when tilesetId changes
• Could add a test for detectBaseUrlFromLocation() with various path scenarios
• Integration test for BASE_URL deployments would catch future regressions

Code Suggestions:

• The appRoutes array in detectBaseUrlFromLocation() could be extracted to a shared constant to avoid duplication across files
• Consider adding JSDoc comments to document the auto-detection behavior

📋 Todo List:

• Read and analyze DashboardMap.tsx changes
• Read and analyze SettingsContext.tsx changes
• Review code quality and implementation approach
• Check for potential bugs and security concerns
• Assess performance implications
• Evaluate test coverage needs
• Provide comprehensive review feedback

🎯 Overall Assessment

Excellent PR! Both fixes are:

• ✅ Targeted and minimal
• ✅ Address root causes effectively
• ✅ Follow React/JavaScript best practices
• ✅ Maintain backward compatibility
• ✅ Have no negative performance or security implications

The implementation quality is high and the changes are ready for merge. The test plan verification confirms the fixes work as intended.

---