Skip to content

Student Dashboard UI Architecture

Executive Summary

The Student Dashboard is the learner-facing interface of the Classroom System. It is engineered to handle classroom enrollment, assignment tracking, multimodal project submissions, and real-time diagnostic feedback via the client-side Autograding Web Worker.

Like the Teacher Dashboard, it follows a strict Container/Presenter pattern. It also uniquely integrates with the Gamification context (useGamification) to surface XP and achievement metrics alongside academic responsibilities.


Page-Level Controllers (The Containers)

1. StudentDashboard.jsx (Global Entry)

This root view manages the student's holistic environment.

  • Enrollment Workflow: Handles the joinCode submission logic via a controlled modal, normalizing the input and executing the joinClassroomByCode API request.
  • Gamification Hook: Integrates DEMO_PROJECTS and XP tracking to render a unified dashboard that mixes formal classroom enrollment (ClassCard components) with self-paced learning objectives.

2. StudentClassDetailPage.jsx (The Orchestrator)

The primary state manager for a specific classroom view (/:classId).

  • State Management: Maintains the active tab state (stream, classwork, people) and the visibility state for the StudentAssignmentModal.
  • Submission Pipeline: Orchestrates the fetching of assignments and merges them with the student's specific getMyAssignmentSubmission state to accurately render whether an assignment is Pending, Submitted, or Graded.

3. StudentProfilePage.jsx (Identity & Session)

Manages the student's localized session data. It interfaces with the updateProfile API to sync academic biographies (e.g., college, branch, semester) and profile images, ensuring the UI reflects the most current JWT claims.


The Submission Pipeline (StudentAssignmentModal)

The StudentAssignmentModal is a highly complex, dual-mode interface that bridges static file uploading with dynamic hardware simulation data.

Mode Toggling

The modal utilizes a viewMode state ('submission' vs 'grading') to switch between the data-entry form and the active Web Worker feedback panel.

Payload Aggregation

When a student clicks "Submit", the modal aggregates several discrete data types into a unified payload for the upsertAssignmentSubmission endpoint:

  1. Raw Notes/Feedback: Standard text strings.
  2. External Links: Array of sanitized URIs.
  3. Multipart Files: Uploaded via the classroomUpload middleware.
  4. Simulator Payloads: If the student pastes a simulator URL, the component automatically extracts the simulationShareId utilizing the getShareIdFromUrl helper regex to link the backend grading engine directly to the standalone Project document.

Client-Side Autograding Execution

While teachers generate the reference keys, students execute the validation against those keys directly within their browser via StudentGradingPanel.jsx. This offloads heavy computation from the server to the client's local CPU.

Off-Thread Comparison

The UI spawns the grading-engine.worker.ts and passes it both the student's current circuit (submissionPngUrl) and the teacher's locked binary target (referenceKeyBase64).

The Audit State Machine

The UI listens to type: 'LOG' messages to advance the visual stepper state:

  1. EXTRACTING: Decoding the student's steganographic PNG.
  2. VALIDATING: Initial syntax/logic check.
  3. COMPILING: Generating executable code.
  4. SIMULATING: Running headless hardware state.
  5. COMPARING: Executing binary diffing against the teacher's key.
  6. AI: Semantic LLM audit for structural fidelity.
  7. FINALIZING: Score generation.

Granular Telemetry

Upon completion, the panel parses the resulting GRADING_COMPLETE payload and renders four distinct granular metrics:

  • Code Behaviour (code_score)
  • Spatial Eye (spatial_score)
  • Fidelity (behavioral_score)
  • AI Semantic Audit (ai_score)

Architecture Note: Diagnostic feedback strings generated by the worker are rendered immediately, providing students with actionable, real-time advice before they commit their final submission to the database.


Technical Debt & UI Constraints

  1. Submission State Desync: The StudentClassDetailPage fetches the global assignment list and the personal submission list separately. Under poor network conditions, a student might see an assignment as "Missing" briefly before the submission state hydrates.
    • Recommendation: Implement an optimistic UI update during the submitAssignment promise resolution to instantly update the local cache before refetching.
  2. Worker Memory Lifecycle: Similar to the teacher panel, the StudentGradingPanel uses a useEffect cleanup to terminate the worker. If a student aggressively toggles between assignments while simulations are running, it could cause brief spikes in browser memory usage.

Released under the MIT License.