ARTDANTECH
0
FREN

Sophie Bluel

Dynamic portfolio for an interior architect. JavaScript front-end integration consuming a Swagger-documented API, authentication, category filtering, and an admin modal to upload/delete media. Accessible, maintainable, and demo-ready application.

Website

1. Context

• Agency: ArchiWebos (50 people). Project: portfolio website for an interior architect.

• Team: you (front-end support), Charlotte (PM/lead), back-end team (API + Swagger), UI/UX (Figma).

• Deliverables: dynamic portfolio page, login page, admin modal (add/delete works), pixel-perfect Figma integration, tested front-end code delivered.

• Starting point: Figma design, back-end (Node + Swagger), original static front, task Kanban.

2. Need

• Populate the gallery from the API, dynamically generate filters, and handle client-side filtering.

• Implement login (auth + token storage) and admin mode (editable UI, “Edit” button, logout).

• Build a media management modal: list, delete, add (image upload form) and update the DOM without reloading.

3. Client / Audience

• Visitors: browse projects by category.

• Client (admin): manage works independently through login + modal.

• ArchiWebos team: clean, maintainable code aligned with the Kanban and matching Figma.

4. Goals

4.1 Functional

• “Works” page: gallery driven by the API, category filters (All + real categories).

• Login: form, redirect, error handling (invalid credentials).

• Admin mode: edit banner/indicators, “Edit” button opening the modal, “Logout” button.

• Modal: two views (Photo gallery with delete, Add photo with preview), form validation, error messages, hot DOM updates.

4.2 Technical

• REST API (Swagger): GET/POST/DELETE with Bearer token for protected operations.

• Front-end: Vanilla JavaScript (fetch, DOM), semantic HTML, existing CSS/Figma respected.

• Auth: token storage (recommended sessionStorage), session check on load, protected actions (401/403 handling).

• Accessibility: semantic structure, alt text, focus management in the modal, aria-*, keyboard support.

5. Constraints / Challenges

• Network/API reliability (timeouts, 4xx/5xx) with clear user feedback.

• Simple, synchronized global state (gallery + modal) to prevent DOM/data divergence.

• Security: avoid unnecessary token exposure, prevent unsafe innerHTML injection, strict file validation (type/size).

• Figma fidelity: spacing, sizing, basic responsive behavior, expected interactions.

6. Process / Methodology

6.1 Analysis

• Read the Kanban, review existing code, run the back-end, open Swagger to list endpoints (e.g. GET /works, GET /categories, POST /users/login, POST /works [multipart], DELETE /works/{id}).

• Define front components: Header/Auth, Gallery, Filters, AdminBanner, Modal (GalleryView + UploadView), API client, Store (state).

6.2 Breakdown into GitHub issues

• Environment setup: clone, install back-end, dev scripts, API baseURL config.

• Step 1.1: fetch works → render dynamic gallery (remove static HTML).

• Step 1.2: generate filters (categories), implement client-side filtering.

• Step 2.1: integrate login page (Figma).

• Step 2.2: POST /login, store token, redirect, display errors.

• Admin mode: show edit banner, toggle UI (hide filters if required, show “Edit” buttons, logout link).

• Step 3.1: modal (open/close, focus trap, two views).

• Step 3.2: delete a work (DELETE), update DOM (gallery + modal).

• Step 3.3–3.4: upload (FormData, POST), validation, preview, immediate render, reset form.

• Step 4: QA (form errors, a11y, minimal responsive, W3C validation, cleanup).

6.3 Architecture & logic

• Front structure: see GitHub repo.

• Flows:

  • On index load: fetch works (+ categories or derived from works), render gallery, build filters.
  • Filter: click → apply predicate on categoryId, update selected visual state.
  • Login: POST /login → store token in sessionStorage → redirect to index → init admin mode (banner + buttons).
  • Modal:
    • Gallery view: list works (trash icon), delete → DELETE → on 200/204 remove from store and from DOM (modal + main gallery). Handle 401/403/404.
    • Upload view: form (image, title, category). Before submit: validations (MIME image/jpeg|png, max size, non-empty title, category selected). FormData → POST /works with Authorization: Bearer <token>. On success: push to store, render immediately in gallery + modal, reset form.

6.4 Technical choices (rationale)

• Vanilla JS: limited scope, maximum clarity/performance, no dependencies.

• sessionStorage for the token (session persistence, reduced risk vs localStorage).

• Use GET /categories when available; otherwise deduplicate categories with a Set derived from works.

• Targeted DOM updates: avoid full re-render when deleting/adding (update only impacted nodes), pure render helpers where possible.

6.5 Main flows

• Visitor: view all works → filter by category → browse updated grid.

• Admin:

  • Login → return to homepage in edit mode (banner, buttons).
  • Open modal → delete a work → item disappears immediately (no reload).
  • Open modal → switch to “Add” view → upload image (preview) → set title/category → submit → new item appears in modal and main gallery → close.

6.6 Tests & quality

• API: validate via Swagger/Postman (GET works, POST login, POST/DELETE works).

• Functional: correct filtering, login error handling (401), logout, modal open/close repeatedly without duplicated DOM, live delete/add behavior.

• Accessibility: alt, tab order, visible focus, aria-modal/role="dialog", Escape to close, focus trap.

• Network errors: user-facing messages (e.g., “Unable to load works”, “Delete failed”).

• Validation: W3C HTML/CSS, no console errors, minimal responsive behavior aligned with Figma.

7. Analysis

• Separating API / Store / UI simplifies DOM updates and ensures consistency between the main gallery and the modal. Isolating auth logic and handling API responses (statuses, messages) produces a robust, predictable front end. A single modal instance prevents leaks and unexpected behaviors.

8. Technical decisions

• fetch with centralized header/error handling; an apiFetch wrapper that throws explicit errors.

• Client-side prevalidation (title/category/image type/size) for UX; server validation remains the source of truth.

• Clean containers before re-render (container.innerHTML = '' then append) or granular updates for performance.

• UX/security: avoid unsafe injection—prefer textContent for titles and sanitize/limit any rich HTML fields.

9. Resolution logic

• Explore and test the API → build dynamic gallery → add filters → implement login/token → enable admin mode → modal display → delete flow → upload flow → refine UX/a11y/error handling.

10. Stack used

• Front: HTML5, existing CSS, JavaScript ES6+ (modules).

• Back: provided Node API (Swagger documentation + tests).

• Tools: VS Code, Live Server, Postman/Swagger, ESLint/Prettier, DevTools (Network, a11y).

• Repo: GitHub, issues/Kanban, feature branches, PR/reviews.

11. Final result

• Dynamic portfolio: API-driven gallery, category filters, working login, visible admin mode, full modal (delete + upload with preview), no-reload updates.

• Quality: clear UX, accessibility respected, errors handled, modular/maintainable code, Figma-compliant and ready for presentation.