prince-chhirolya/dsa_platform

1. This repository is a static, client-rendered study guide site built with Vite + React. It does not appear to have a backend or database; the whole product is assembled from Markdown content plus client-side navigation and search.

2. The core domain boundary is the DSA content library. Topic-level Markdown files live under content/ and mirror the major interview-prep areas in the README: arrays, binary search, DP, graphs, greedy, heaps, range queries, stacks/queues, tries, and two-pointers/sliding-window. These files are the primary source of truth for the learning material.

3. There is a second content copy under public/content/ and a generated output under dist/content/. That suggests a publish/build flow where authored Markdown is prepared for static serving, then emitted into the production bundle. The app is therefore content-driven rather than code-driven.

4. The app shell lives in src/App.jsx, with global styling in src/App.css and src/index.css, and the entrypoint in src/main.jsx. The UI is organized around a home page, a markdown-reading page, sidebar navigation, a topbar search trigger, and a search palette. This implies a single-page app with route-like view switching handled on the client.

5. Markdown rendering is a distinct subsystem. src/lib/markdownParse.js likely converts the topic files into renderable page structure, while src/components/MarkdownPage.jsx is the presentation layer for article pages. The architecture separates content parsing from the UI components that display it.

6. Search is a major feature and has its own boundary. scripts/buildSearchIndex.mjs likely precomputes a search corpus from the Markdown content, while src/search/useSearchIndex.js, parseQuery.js, highlight.jsx, and useRecentSearches.js implement the client-side search experience. That means search is built mostly at compile time, then consumed interactively in the browser.

7. There is a content-metadata/indexing layer at build time. vite-plugins/content-index.js and scripts/addFrontmatter.mjs indicate the repository generates or enriches frontmatter/index data from the Markdown files, so the app can list topics, subtopics, and searchable metadata without manual duplication.

8. The src/conceptMaps.js file and src/concepts_maps/ directory form another data subsystem. These files likely encode structured relationships between patterns, such as topic maps or cross-topic concept graphs, which support the “pattern-first” organization described in the README.

9. src/topics.js is the topic registry layer. It likely defines the canonical ordering and display names for the ten main sections, acting as the bridge between the content files and the navigation/sidebar UI.

10. The repository has a clear authoring-to-runtime pipeline:

- source Markdown in content/

- build-time augmentation/indexing via scripts and the Vite plugin

- generated static assets in dist/

- client app in src/ rendering pages and search from prebuilt content/index data.

11. The README.md is not just documentation; it is effectively the product manifest. It defines the repository’s information architecture: topic taxonomy, study phases, cross-topic reuse, and the intended learning flow. That structure is reflected in the content organization and likely in the sidebar and search UI.

12. For an architecture diagram, the key boundaries are: content authoring, build-time content processing, client-side rendering, and client-side search. The only external dependency that materially matters is the static build toolchain itself; everything else is local file-based data flow.