saifurrahmanshochib/markdown-viewer

1. Overall shape

- This is a self-hosted Next.js Markdown editor/viewer. The repository is dominated by a single interactive app rather than a multi-service backend.

- The core architecture is client-heavy: editing, previewing, tools, and export are handled in the browser, with Next.js mainly providing the app shell, bundling, and deployment.

2. Application shell

- app/layout.tsx, app/page.tsx, and app/globals.css define the root Next.js App Router shell.

- components/providers.tsx likely wires global client-side concerns such as theme, toast notifications, and other context providers.

- The app is styled with Tailwind CSS and uses a shared UI component system under components/ui/.

3. Primary user experience: the editor workspace

- The main functional boundary is components/editor/, which contains the full Markdown editing workspace.

- Key parts include the editor surface (markdown-editor.tsx, textarea-editor.tsx), preview panel (markdown-preview.tsx), and surrounding controls such as editor-toolbar.tsx, editor-status-bar.tsx, and editor-loader.tsx.

- This suggests a split-view / mode-switching editor where the document is edited on one side and rendered on the other.

4. Document flow: input → transform → preview

- User text enters the editor component, is processed through Markdown utilities in lib/markdown.ts, and then rendered in the preview component.

- Supporting transformations live in lib/html-to-markdown.ts and lib/emoji.ts, implying bidirectional content handling for pasted HTML and emoji normalization.

- The preview path likely includes enhanced Markdown features called out in the README: GFM, syntax highlighting, KaTeX math, and Mermaid rendering.

5. Draft persistence and local state

- Drafts are stored client-side through hooks/use-local-storage.ts, which aligns with the README’s localStorage-based draft behavior.

- components/editor/drafts-bar.tsx is the UI boundary for managing saved drafts, while hooks/use-debounce.ts likely reduces write frequency and expensive transforms while typing.

- This is an important architectural point: there is no central backend document store in the repo; persistence is local to the browser.

6. Editor tools and auxiliary analysis

- components/editor/tools-sidebar.tsx is the container for non-editing utilities such as outline, linting, stats, and tables.

- find-replace.tsx, editor-toolbar.tsx, and editor-status-bar.tsx provide editor operations and live document metadata.

- These tools consume the same document state as the editor and preview, but are visually and functionally separate subsystems.

7. Specialized content blocks

- components/editor/mermaid-block.tsx indicates explicit handling for Mermaid diagrams as a first-class Markdown extension.

- That implies the rendering pipeline has content-type-aware branches rather than treating the document as plain Markdown only.

- This is a notable diagram boundary: standard Markdown rendering versus embedded diagram blocks.

8. Export and output paths

- lib/export.ts provides the document output layer, supporting formats mentioned in the README such as Markdown, HTML, PDF, and print.

- Export likely depends on the current editor state and rendered HTML, making it a downstream consumer of the same document model used by the preview.

- This makes export a separate architectural branch from live editing, even though both originate from the same document content.

9. Shared UI and interaction infrastructure

- components/ui/ contains reusable primitives like dialog, button, tabs, toast, tooltip, input, switch, and scroll area.

- These are the building blocks used across editor controls, confirmations, settings, and transient messages.

- hooks/use-toast.ts plus components/ui/toaster.tsx provide the global notification path for user feedback.

10. Platform/runtime and delivery

- The project targets Node.js 18.17+ and uses Docker as a first-class packaging/deployment path (Dockerfile, docker-compose.yml).

- next.config.mjs, middleware.ts, tailwind.config.ts, postcss.config.mjs, and tsconfig.json show a standard Next.js + TypeScript frontend stack with build-time optimization and request-level middleware.

- Dockerfile is described as a multi-stage image using Next.js standalone output, which means the deployable artifact is a self-contained server bundle rather than a separate web server plus app.