molimen/o-matic

This repository is a client-side single-page application built with Vite, React, TypeScript, and plain CSS. There is no backend code in the repo; all behavior appears to happen in the browser, with data either fetched from external sources through service modules or stored locally.

The application entry point is src/main.tsx, which bootstraps App.tsx into index.html. App.tsx is the top-level composition and is the likely place where page selection/routing and global app structure are wired together.

The app is organized around page-level feature screens in src/pages: Home, About, AlterEgo, Kel-o-matic, Petto, Seat-o-matic, and NotFound. The naming suggests a set of distinct tools or mini-apps rather than one uniform workflow, so the main architectural boundary is “page/feature” rather than “model/domain” in the classic sense.

Shared UI is concentrated in src/components. The user-input subfolder contains reusable form controls such as buttons, number inputs, select inputs, color pickers, and message display. These are the building blocks for the interactive pages and are likely reused across multiple tools.

There is a small notification subsystem in src/components/notification/notificationWindow.tsx. This indicates a cross-cutting UI concern for transient feedback, probably triggered by user actions on the feature pages rather than managed as a separate domain.

The src/services folder contains getStudentsData.tsx and getBlacklistsData.tsx, which represent the data-access boundary of the app. These modules likely encapsulate fetching and parsing of external or remote data so the page components do not deal directly with transport concerns.

The src/utils folder contains the app’s reusable logic and small helpers: classData, hexToBrightness, language, shuffleArray, and useLocalStorage. This suggests the app depends on client-side data shaping, visual calculations, language/text handling, randomization, and persistence in browser storage.

useLocalStorage is especially important architecturally because it implies user preferences or generated state survive page reloads without a server. That makes browser storage part of the persistence layer alongside any fetched service data.

Static assets live under public, including fonts, icons, and image sets such as carousel images. These are part of the presentation layer and are loaded directly by the browser rather than through the TypeScript module graph.

Styling is split between src/index.css for global styles and component/page-local structure in the React components. There is no sign of a CSS framework; the layout is likely custom-styled.

Tooling is standard frontend app tooling: TypeScript config files, ESLint, Prettier, and package-lock.json for deterministic installs. vite.config.ts indicates Vite is the build/dev server and module bundler, which matters because the app is designed to be shipped as static frontend assets.

From an architecture-diagram perspective, the main flow is: browser entry → app shell → page feature component → shared inputs/utilities/services → browser storage and/or external data → UI feedback via notifications. The main boundaries are feature pages, shared components, service/data access, and utility logic.