Portfolio to Playground Reconstruction
ARCHITECTURE •
Situation
The original portfolio system used file-based dynamic routes ([slug] pattern) where each project had its tsx files.
Additionally, the term "portfolio" felt too formal for experimental tech demos and learning projects.
For items that can have their own layouts for each, a dynamic routing system with unified layout was not appropriate.
To disclose the purpose of this section more clearly, rebranding and reconstruction were inevitable.
Task
Redesign the portfolio architecture to:
- Rebrand from "portfolio" to "playground" to better reflect the experimental nature.
- Switch to static routing system to enable various layouts for each item.
- Provide alternative for each item's entry point. Since no longer utilizing dynamic routing system, automatic entry point generation (previously with card component) will be lost.
- Adopt the proven architectural pattern from
cesium-utils. (private folders, centralized config) - Ensure type safety and prevent runtime errors from missing data
Action
1. Conceptual Rebranding
- Renamed
/portfolioto/playgroundacross the codebase. - Updated terminology: "portfolio items" → "playground items".
2. Routing System Migration
- Removed dynamic
[slug]routes and individual projecttsxfiles. - Created static routes under
/playground, enabling independent layouts per item.
3. Entry Point Generation
- Created
apps/web/app/playground/_data/index.tsas single source of truth, followingcesium-utilspattern. - Entry points for each playground item are sourced from centralized data, displayed by
PlaygroundItemcomponent.
4. Component Architecture
- Followed existing
cesium-utilspattern. Private folders for feature isolation and cohesion, with centralized item configuration. - Built reusable
PlaygroundItemcomponent with consistent styling. - Removed file-based routing utilities (slug generation, file-system utility).