Files

T

CI / quality (push) Waiting to run

Details

refactor: drop toast + over-engineered extras, add inline admin feedback

Phase 1 cleanup of the personal-site revamp. Backend/architecture untouched;
changes are limited to removing unused complexity and restoring feedback.

Removals
- Toast system: delete react-hot-toast, Toaster, QueryToastBridge, lib/toast,
  the toggle/easter-egg calls, related i18n keys and the dependency.
- Contact protection: remove Turnstile + per-IP rate limiting
  (lib/contact-guard, lib/contact-protection, admin screen, form widget,
  app-config wiring, nav entry, test).
- Speculative specs: delete orders, products, downloads, project-inquiry.

Inline feedback (replaces toast, no new deps)
- Add lib/admin-feedback (withFlash/readFlash) and components/admin/admin-flash,
  rendered centrally by AdminDashboardShell.
- Emit success/error messages for media, site-settings, portfolio, smtp,
  marquee and maintenance actions; pages read them via searchParams.
- Contact form shows validation/delivery errors inline; success still
  redirects to /success.

Docs
- Fix stale paths in frontend-system-* (components/root -> components/admin,
  lib/root-navigation -> lib/admin-navigation, drop phantom src/) and remove
  contact-protection references from docs and CLAUDE.md.
- Add docs/PHASE0_DIAGNOSIS.md (diagnosis report).

Note: proxy.ts self-fetch kept intentionally; it also drives maintenance mode.

2026-07-14 21:03:51 +02:00

3.8 KiB

Raw Blame History

Architecture

Stack

Next.js (App Router)
TypeScript
next-intl
Prisma + PostgreSQL
Tailwind CSS
Radix UI (via local primitives)
framer-motion
nodemailer

Application Structure

Public application

Localized public pages live under:

app/[locale]/(site)

Locale routing and configuration are defined in:

i18n/routing.ts

The public layout checks the maintenance status and redirects visitors to:

/coming-soon

when maintenance mode is enabled.

Admin application

Admin pages are implemented under:

app/_admin

Internal admin routing is rewritten to:

app/admin-internal

Development alias routes also exist under:

app/root

Routing decisions and host/path-based rewrites are implemented in:

lib/admin-routing.ts

The _admin structure should be treated as the canonical admin source.

Core Modules

Application logic lives primarily in lib/*.

Important modules include:

lib/portfolio.ts
Handles portfolio queries and localized mapping.

lib/app-config.ts
Provides application-level configuration values.

lib/media.ts
Handles media library queries and media bindings.

lib/mail.ts
Handles SMTP delivery via nodemailer.

These modules act as the primary server-side application layer.

UI Layer

Shared UI primitives live in:

components/ui

These primitives wrap Radix UI components and define the shared design system.

Public site UI components live in:

components/site
components/layout

Admin UI components live in:

components/admin
components/dashboard

Shared primitives must always originate from components/ui.

Feature-level UI should reuse these primitives rather than reimplementing them.

Persistence Layer

Database access is implemented using Prisma.

Prisma client lives in:

lib/prisma.ts

Configuration values are stored in the database via:

AppConfig

which acts as a key-value store for runtime configuration values.

Database access should always occur through server-side modules.

Client components must never access Prisma directly.

Architectural Boundaries

The following boundaries must be respected:

Client components must not access Prisma.
Business logic must not live inside UI components.
Shared UI must originate from components/ui.
Public site UI belongs in components/site.
Admin UI belongs in components/admin or components/dashboard.
Server actions act as request entry points for form submissions.
Server actions may call modules in lib/*.

Database queries should not be implemented directly inside route-level UI files.

Request Flow Examples

Contact submission

User submits the form on

app/[locale]/(site)/contact/page.tsx

Server action validates the input using Zod.
Email is sent through:

lib/mail.ts

The user is redirected to:

/success

or back to the form with an error state.

Portfolio publishing

Admin edits a project form.
Server action validates categories, fields, sections, and assets.
Media selections are resolved via:

lib/media.ts

Project data, sections, assets, and media usage are persisted via Prisma.
Public and admin paths are revalidated.

Canonical Sources

The following files should be treated as canonical sources for specific domains:

Routing
i18n/routing.ts

Admin routing
lib/admin-routing.ts

Prisma access
lib/prisma.ts

Application configuration
lib/app-config.ts

Portfolio logic
lib/portfolio.ts

Media handling
lib/media.ts

Proposed Future Improvements (Not Implemented)

These ideas are not currently implemented but may be introduced later:

Split app-config concerns into smaller modules if additional domains are added.
Introduce dedicated models instead of expanding the AppConfig key-value store.
Introduce explicit service boundaries if the application grows significantly.ڑ

3.8 KiB Raw Blame History