atomic-page
Scannednpx machina-cli add skill andireuter/skills-webapp/atomic-page --openclawAtomic Design: PAGE (React Functional Components)
You are creating a PAGE: a route-level component that binds UI to real data and app concerns.
Hard rules
- Functional components only.
- Orchestration lives here:
- Data fetching (via the project’s standard: loaders, query libs, server components, etc.)
- Side effects (analytics, navigation, subscriptions) in
useEffector framework equivalents
- Keep UI reusable:
- Prefer pushing rendering into templates/organisms; keep pages thin.
- Error/loading states:
- Must have consistent handling aligned with the repo’s conventions.
- Performance:
- Avoid waterfall fetching; colocate queries where the project expects.
- Memoize expensive derived data with
useMemowhen justified.
Output expectations
- Provide:
Page.tsxPage.test.tsx(routing + async states, if applicable)- A brief note explaining which layer owns which responsibility (page vs template vs organism).
Recommended folder conventions
src/pages/<PageName>/...(or framework equivalent)
Source
git clone https://github.com/andireuter/skills-webapp/blob/main/skills/atomic-page/SKILL.mdView on GitHub Overview
A PAGE is a React functional component that acts as the route-level container, binding templates and organisms to real app data and routing. It handles data loading, orchestration, and side effects, keeping UI concerns thin by delegating rendering to templates/organisms. It also enforces consistent error and loading states and aims to colocate queries for performance.
How This Skill Works
Built as a functional component that orchestrates data loading using the project’s standard loaders or query libraries. It passes data down to templates/organisms, while managing side effects (analytics, navigation, subscriptions) in useEffect or framework equivalents. It ensures consistent error/loading states per repo conventions and uses useMemo to memoize expensive derived data when justified.
When to Use It
- When a route-level page must bind real app data to UI via templates/organisms
- When the page coordinates multiple data sources with colocated queries
- When consistent, centralized error and loading states are required for a route
- When you need to run analytics, navigation, or subscription side effects on the page
- When you want to keep UI components reusable by keeping the Page thin and delegating rendering
Quick Start
- Step 1: Create src/pages/<PageName>/Page.tsx as a functional Page component
- Step 2: Implement data loading using the project’s loaders/query libs and pass data to templates/organisms
- Step 3: Add routing+async state tests in Page.test.tsx and document which layer owns which responsibility
Best Practices
- Keep the Page thin; push rendering into templates/organisms and minimize UI logic in the Page
- Use the project’s standard data-loading approach (loaders, query libs) for data fetching
- Place side effects (analytics, navigation, subscriptions) in useEffect or framework equivalents
- Ensure error/loading states follow repo conventions for consistency
- Memoize expensive derived data with useMemo and avoid unnecessary re-renders
Example Use Cases
- UserProfilePage binds real user data to a ProfileTemplate and UserCard organism
- ProductDetailPage loads product data and pricing, rendered through a ProductTemplate
- DashboardPage orchestrates multiple widgets (organisms) and fetches stats without waterfall calls
- SettingsPage fetches user preferences and applies analytics on mount
- BlogPostPage fetches post and author data, rendering via a BlogLayout template
