feat: add admin chapter content editor

[Aish-kul16]

Closes #77

Description

Added an admin chapter content editor at:

/admin/chapters/[chapterId]/edit

Features Implemented

• Split-panel markdown editor
• Live markdown preview
• Content validation for empty content
• Upload content from .md and .txt files
• Clear/reset content option with confirmation
• Content source display (Manual / Uploaded / Draft)
• Confirmation before overwriting existing content
• Auto-save draft every 30 seconds using localStorage
• Draft restoration on page refresh

Testing

• Verified live markdown preview updates while typing
• Verified validation appears when content is empty
• Verified uploaded markdown files populate editor and preview
• Verified overwrite confirmation before file upload
• Verified auto-save and draft restoration after refresh
• Verified content source updates correctly

[vercel]

@Aish-kul16 is attempting to deploy a commit to the Adarsh's projects Team on Vercel.

A member of the Team first needs to authorize it.

[MRIARC-08]

Thanks for the contribution! The editor UI is a good start and it covers some parts of the issue like split-panel editing, live preview, file upload, clear option, and draft autosave.

However, this does not fully meet the issue requirements yet. The editor needs to work for a real chapter at /admin/chapters/[chapterId]/edit, fetch the existing chapter markdown content, and save the updated content back to the database. Currently, the Save and Cancel buttons do not perform any action, the content starts from placeholder text, and the localStorage draft key is global instead of being chapter-specific.

Please update the PR to:

• use the [chapterId] route properly
• fetch the current chapter content before editing
• connect the Save button to the chapter update API/server action
• make Cancel return back or reset to the original content
• make the draft key chapter-specific
• show the actual content source from the chapter data, not only local state
• improve validation beyond only checking empty content

Once these are handled, this should be much closer to the expected outcome.

[Aish-kul16]

Hi @MRIARC-08 , thank you for the feedback i will do the following changes and update you soon.

[Aish-kul16]

Hi @MRIARC-08 I've updated the PR to address the requested changes:

• Uses the /admin/chapters/[chapterId]/edit route properly
• Fetches existing chapter content from the database before editing
• Displays the actual content source from chapter data
• Connects the Save action to a backend update flow and persists changes
• Makes Cancel reset the editor back to the original loaded content
• Uses chapter-specific draft keys for autosave
• Improves validation beyond empty-content checks

[MRIARC-08]

@Aish-kul16 This update still exposes an unauthenticated PATCH endpoint that can modify chapter content. The route must enforce authenticated admin authorization. The editor also never initializes originalContent, so Cancel resets to an empty value, and it targets the old MarkdownRenderer path instead of the live reader. Please address these functional and authorization blockers.

[Aish-kul16]

Hi @MRIARC-08 I've fixed the originalContent initialization issue so Cancel now restores the loaded chapter content correctly.

I'm currently working on the admin authorization requirement for the PATCH endpoint.

For the comment about "targeting the old MarkdownRenderer path instead of the live reader", could you point me to the intended reader component/path that should be used for the preview? I wasn't able to identify the live reader from the current codebase and want to make sure I align the implementation with the existing architecture.

[MRIARC-08]

@Aish-kul16 Thanks for the update. GitHub still shows no commit after the latest authorization/config review. Please push the completed changes, including the admin-authorization fix, and tag me when the branch is ready for another pass.

[Aish-kul16]

@MRIARC-08 I've pushed the latest changes addressing the review feedback:

• Fixed originalContent initialization so Cancel restores the loaded chapter content.
• Added admin authorization checks for chapter content updates.

The branch is ready for another review pass.

For the "live reader" comment, I'm still not sure which reader component/path should be used instead of MarkdownRenderer. If there's a specific component you'd like me to target, please let me know and I'll update it accordingly.

[MRIARC-08]

@Aish-kul16 The admin check and originalContent initialization are now present. The live reader component you asked about is src/components/MarkdownViewer.tsx, used by ChapterContent.tsx; the editor still previews through the legacy MarkdownRenderer. The save handler also shows success without checking res.ok, so a 401/403/500 is reported as saved. Please switch the preview to MarkdownViewer, handle non-success responses, and clean the focused lint output (90 formatting errors plus unused state/hook dependency warnings).

[Aish-kul16]

Thanks for the clarification @MRIARC-08,

I found src/components/ChapterContent.tsx, but in my current checkout it imports and renders MarkdownRenderer:

import MarkdownRenderer from '@/components/MarkdownRenderer';

<MarkdownRenderer content={chapter.content ?? ''} />

I wasn't able to find a src/components/MarkdownViewer.tsx file in the repository. Could you confirm whether MarkdownViewer.tsx exists on a different branch/version, or if MarkdownRenderer is the component you intended me to use?

[MRIARC-08]

@Aish-kul16 Current main uses src/components/MarkdownViewer.tsx from src/components/ChapterContent.tsx. Your branch still needs to sync with current main, switch the editor preview to the active viewer where appropriate, and handle failed save responses before showing success. Please also rerun the formatter/lint after rebasing.

[Aish-kul16]

@MRIARC-08 I've rebased onto current main and updated the editor to use MarkdownViewer instead of MarkdownRenderer. I also added failed-response handling so the save action only reports success when res.ok is true, and the admin authorization/originalContent fixes remain in place.

While rerunning lint after the rebase, I hit the newer react-hooks/set-state-in-effect rule on the draft restoration effect (localStorage → setContent). I investigated existing patterns in the codebase (e.g. ResumeCard) but the rule still flags this editor initialization path after the rebase.

Before removing or restructuring the draft restoration behavior, I'd appreciate guidance on the preferred pattern for this codebase so I can keep the feature while satisfying the updated lint rules.

[MRIARC-08]

@Aish-kul16 For the react-hooks/set-state-in-effect issue, prefer avoiding an effect whose only job is to read localStorage and immediately call setState.

For draft restoration, use one of these patterns:

• If the initial value can be read synchronously on mount, use a lazy initializer: useState(() => loadDraftFromStorage() ?? initialValue).

• If the draft depends on fetched chapter content, load the chapter first, compute the restored content inside that same async path, then set content, originalContent, and any draft flag together. Avoid a separate “read localStorage -> setContent” effect.

• If you need to react to route/chapter changes, key the restored state by chapterId and clear/recompute it in the data-loading function, not in a standalone hydration effect.Please push that restructuring plus the remaining formatter fixes, then I can re-review the editor behavior.

[MRIARC-08]

@Aish-kul16 Thanks for the update. The branch now merges cleanly and the previous draft-loading direction is better, but it still needs changes before merge.

Local checks:

• pnpm exec tsc --noEmit passes.
• pnpm test passes: 8 files / 35 tests.
• Focused ESLint on the touched admin/NCERT files fails with 46 Prettier errors.

Functional blocker after latest main changes: GET /api/ncert/chapter now requires the parent class and subject context, but the editor still loads with only chapterId:
/api/ncert/chapter?chapterId=${chapterId}

That will fail against current main. Please update the editor/load route to use the current NCERT chapter API contract or add a properly authorized admin-specific fetch path for chapter editing.

After that, run the formatter. Since this adds an admin editor UI, it will still need manual UI review before merge.

[Aish-kul16]

@MRIARC-08 Thanks for the review. I tracked down the recent NCERT route validation changes (#426) and see that the public GET /api/ncert/chapter endpoint now requires classId, subjectId, and chapterId.

The current admin editor route is still /admin/chapters/[chapterId]/edit, so it only has access to chapterId. Before I change the routing, I'd like to confirm the intended approach:

• Should the admin editor route be updated to include the parent classId and subjectId so it can call the current public API contract?
• Or would you prefer a dedicated admin-authorized fetch endpoint that loads a chapter by chapterId for editing?

I can implement either approach; I just want to align with the intended architecture before making that change.