Split PanelViews.tsx into per-panel files (needs a shared-data design first)

[jgupta05072003-code]

What this is for

frontend/src/components/PanelViews.tsx is 1,665 lines and, like RoleDashboards.tsx (#136), renders a different screen depending on which nav item is active (if (panel === 'reports') { ... }, if (panel === 'districts') { ... }, etc. — about 20 of these).

This one is harder than #136 and needs some design thought before jumping in, so it's not broken into ready-to-go sub-issues yet the way #136 was. Read this whole issue before starting.

Why it's harder than the RoleDashboards split

RoleDashboards.tsx's 8 dashboards are fully independent — no shared code between them. PanelViews.tsx is different: at the top of the component there's a shared block of state, data-fetching, and helper functions that almost every panel branch below it depends on — things like:

• students, schools, usersList, reportsList, teachersList (the fetched/fallback data)
• getDistrictStats(stateCode), getBlockStats(districtCode) (aggregation helpers)
• Various useState/useEffect hooks for search, filters, selected student, etc.

If you just cut a panel branch out into its own file, it'll break unless you also pass all the shared stuff it needs in as props (or find some other way to share it, e.g. a custom hook).

What needs to happen first (do this before moving any panel)

1. Read through PanelViews.tsx top to bottom and list, for each panel branch, which of the shared variables/functions/state it actually uses (many panels only need 2-3 of them, not all).
2. Design a shared pattern — the simplest is probably a custom hook (e.g. usePanelData(token, currentUser)) that returns { students, schools, usersList, reportsList, teachersList, getDistrictStats, getBlockStats }, which every extracted panel file can call.
3. Propose the design (a short comment on this issue, or a small draft PR) before doing the full extraction — this is the part most worth a second pair of eyes.
4. Once the shared-data pattern is agreed, this can be broken into per-panel sub-issues the same way Epic: split RoleDashboards.tsx into one file per dashboard #136 was for the dashboards.

How to check your work (once you get to actually moving panels)

1. cd frontend && npm run lint — no errors.
2. npm run build — succeeds.
3. Run npm run dev and click through every panel for every role that can see it — confirm identical behavior to before (this file has more panels reachable by more roles than RoleDashboards, so there's more to check).

Not in scope here

No behavior or logic changes — this is purely about making the file smaller and easier to navigate, not changing what anything does.

[jgupta05072003-code]

Step 1 — usage map (every panel branch → what shared state it actually touches)

Went through all 20 if (panel === ...) branches and grepped each block's line range against every shared variable/function declared at the top of the component. Full result:

Panel	Lines	Shared data used
student_list	8	students
student_profile	539	sel/setSel, profileTab/setProfileTab, editingProfile/setEditingProfile, profileDraft/setProfileDraft, savingProfile/setSavingProfile, searchQuery/setSearchQuery, showDropdown/setShowDropdown, activityFilter/setActivityFilter, students, schools, reportsList, handleDownloadPDF
diagnostic_test	28	students
adaptive_test	20	(none)
test_history	13	(none — uses its own local DIAGNOSTIC_HISTORY mock)
worksheets	63	students, reportsList, worksheetsList
performance	26	students
reports	109	expandedDistRpt/setExpandedDistRpt, students, schools, reportsList, handleDownloadPDF
assigned_schools	19	students, schools
student_progress	14	students, schools
attendance	35	students, reportsList
teachers	21	students, schools, teachersList
schools	27	stateFilter/setStateFilter, distFilter/setDistFilter, blockFilter/setBlockFilter, schools, filteredSchools
districts	82	expandedDist/setExpandedDist, students, schools, getDistrictStats
blocks	16	students, schools, getBlockStats
users	68	userRoleFilter/setUserRoleFilter, userSearch/setUserSearch, usersList
worksheet_templates	14	(none — local WS_TEMPLATES mock)
content	118	search/setSearch
analytics	30	students, schools, getDistrictStats, getBlockStats
system_settings	33	(none — local SYSTEM_LOGS_MOCK mock)

Key observation confirming the issue's premise: every panel that touches shared data only ever needs some subset of {students, schools, usersList, reportsList, worksheetsList, teachersList, getDistrictStats, getBlockStats} — none of the 20 panels need all of them, and the filter/search/edit UI state (search, stateFilter, sel, profileTab, editingProfile, userRoleFilter, etc.) is used by exactly one panel each, never shared across two.

Also found while mapping this: CONTENT_ITEMS (top-of-file mock array, line 84) is dead — defined but never referenced by the content panel or anywhere else. Flagging only, not fixing here (out of scope for this issue's "no behavior change" rule) — worth a 1-line follow-up cleanup once content is split out.

Step 2 — proposed design

A. Data hook — frontend/src/components/panels/usePanelData.ts

export function usePanelData(token: string, currentUser: User, activePanel: string) {
  // ...moves the 3 useEffects, the 6 apiFetch calls, the 4 *_FALLBACK/MOCK
  // constants, and the students/schools/usersList/reportsList/worksheetsList/
  // teachersList derivations + getDistrictStats/getBlockStats verbatim...
  return { students, schools, usersList, reportsList, worksheetsList, teachersList, getDistrictStats, getBlockStats };
}

Every extracted panel file calls usePanelData(token, currentUser, activePanel) and destructures only what it needs — e.g. student_list takes just { students }, users takes just { usersList }. Matches the issue's suggested shape exactly.

B. UI state stays local, not in the hook. Since the mapping above shows zero cross-panel sharing of filter/edit/search state, each extracted panel keeps its own useState calls rather than centralizing them — centralizing would mean every panel re-renders on any panel's local state change, a real regression this file doesn't have today.

C. Shared presentational bits — frontend/src/components/panels/PanelShared.tsx
PageHeader (used by all 20 panels) and EmptyStudents (used by student_list) move here as plain exported components — no state, trivial to share.

D. Shared pure helper — frontend/src/components/panels/pdfReportGenerator.ts
handleDownloadPDF doesn't close over any component state — it only takes (student, report) as parameters — so it becomes a plain exported function, imported by both student_profile and reports (the only two panels that use it) instead of being redefined per-panel.

E. Per-panel mock/fallback data moves with its panel, not into the shared hook: WS_TEMPLATES → worksheet_templates panel file, DIAGNOSTIC_HISTORY → test_history, SYSTEM_LOGS_MOCK → system_settings. Only the 4 datasets actually referenced inside usePanelData (STUDENTS_FALLBACK, SCHOOLS_FALLBACK, USERS_FALLBACK, TEACHERS_MOCK) move into the hook file itself.

F. Resulting structure:

frontend/src/components/panels/
  usePanelData.ts          (shared data hook)
  PanelShared.tsx           (PageHeader, EmptyStudents)
  pdfReportGenerator.ts     (handleDownloadPDF)
  StudentListPanel.tsx
  StudentProfilePanel.tsx   (largest, 539 lines — still worth a sub-issue of its own given the size)
  DiagnosticTestPanel.tsx
  AdaptiveTestPanel.tsx
  TestHistoryPanel.tsx
  WorksheetsPanel.tsx
  PerformancePanel.tsx
  ReportsPanel.tsx
  AssignedSchoolsPanel.tsx
  StudentProgressPanel.tsx
  AttendancePanel.tsx
  TeachersPanel.tsx
  SchoolsPanel.tsx
  DistrictsPanel.tsx
  BlocksPanel.tsx
  UsersPanel.tsx
  WorksheetTemplatesPanel.tsx
  ContentPanel.tsx
  AnalyticsPanel.tsx
  SystemSettingsPanel.tsx

PanelViews.tsx becomes a thin router: reads activePanel, calls usePanelData once, and renders the matching <XPanel .../>, mirroring what RoleDashboards.tsx already does post-#136/#243/#244.

Once this is agreed, happy to break it into per-panel sub-issues the same way #136 was for the dashboards (small panels bundled a few per issue, student_profile as its own issue given its size).