Frontend refactor. Solves #179 and advances #249

[ahmedbektic]

Description

This PR resolves issue #179 by removing legacy local-file dashboard behavior and consolidating the frontend around backend-driven report data flow. It also includes targeted cleanup and dead-code pruning completed on FRONTEND-REFACTOR, plus conflict resolution from syncing with main and final UI polish.

Related to #249: this PR delivers high-confidence cleanup and backend-flow stabilization that reduces legacy data-path complexity and de-risks the later full frontend data-framework migration.

Why

The old Dashboard.jsx path depended on local file selection/parsing, which conflicts with the current backend-managed architecture. Maintaining both patterns increased complexity, left stale code paths, and made navigation/state handling fragile.

Where

• Routing and dashboard/report flow:
  • frontend/src/App.js
  • frontend/src/components/ReportDashboard.jsx
  • frontend/src/components/FuzzyDashboard.jsx
  • frontend/src/components/HorizontalLinearStepper.jsx
• Tests and coverage:
  • frontend/src/tests/FuzzyDashboard.test.jsx
  • frontend/src/tests/App.test.js
  • frontend/src/tests/EnvironmentConfiguration.test.jsx
  • frontend/cypress/e2e/app.cy.js
• Cleanup and structure:
  • Removed dead components/pages (Dashboard.jsx, DroneDetails.jsx, SimulationPage.jsx, SimulationConfigs.jsx, legacy AboutUs.jsx)
  • Removed unused MonitorModel.js and reference
  • Removed stale redux/utility leftovers with no active references
  • Moved LandingPage.jsx into pages/ and updated imports/usages
  • Removed legacy /report-dashboard compatibility route
• Final UI touches:
  • frontend/src/pages/Home.jsx (centered backend status + queued tasks blocks)
  • frontend/src/components/ReportDashboard.jsx (forced dark section-title color for readability)

How

1. Removed dead/legacy dashboard entry points.
2. Deleted legacy local-file/commented upload remnants from dashboard-related flow.
3. Standardized report loading and preview/download via backend APIs (/list-reports, /list-folder-contents, /download-report).
4. Hardened direct /dashboard access behavior when route state is missing.
5. Implemented submit-then-navigate flow to /reports from simulation completion.
6. Added/updated unit + e2e coverage for critical dashboard/report navigation paths.
7. Performed incremental cleanup of dead code, stale comments, unused imports/variables, and redundant files.
8. Synced with main, resolved conflicts, and applied final UI/readability fixes.

Notes

• Scope includes issue Refactor Dashboard.jsx to Remove Local File Dependencies #179 requirements plus high-confidence cleanup that reduced maintenance burden.
• Validation included route-level behavior checks and expanded test coverage for dashboard/report flow.

Acceptance Criteria Mapping

• Remove local file handling code (file inputs + local parsing logic)
• Integrate remote backend data flow for reports/dashboard
• Refactor/cleanup redundant local-file/local-storage-era code
• Ensure navigation/data continuity between ReportDashboard and dashboard view
• Add evidence via tests/manual flow hardening for monitor/report display paths

Addendum: Relationship to #249 (Refactor Frontend Data Systems)

This PR does not claim to fully implement #249, but it materially advances the same direction by removing legacy flows and tightening backend-driven data paths.

What This PR Advances

• Standardizes report/dashboard data flow on backend APIs (list-reports, list-folder-contents, download-report), reducing divergent frontend data paths.
• Removes local-file-era dashboard logic and dead components, lowering complexity and making future data-layer changes safer.
• Hardens navigation/state behavior (/dashboard fallback handling, submit-then-navigate to /reports) so data transitions are more deterministic.
• Adds test coverage around dashboard/report flow, improving confidence for future frontend data-system refactors.

What This PR Does Not Complete From #249

• Does not introduce or document a new React data framework replacing current useEffect-driven patterns.
• Does not fully replace existing data methods across all configurators with one unified global approach.
• Does not explicitly abolish the “2 controller system” architecture end-to-end.
• Does not certify dockerized POST validation as a dedicated acceptance target.

Positioning

This PR should be treated as a foundational cleanup and stabilization step that reduces technical debt and de-risks a future full data-framework refactor.

[CharlieWells13]

Awesome job on getting rid of a lot of the junk, it makes understanding our codebase as a new developer much easier.