React Container Presentation Component

Container/Presentation Component

Use this skill to create a React component under src/components that follows the Container/Presentation pattern.

Refer to this skill's bundled references for detailed rules.

• references/component-architecture.md
• references/typescript-and-scss-rules.md

If the /react-container-presentation-component input is incomplete, ask questions first before creating files.

When To Use

• When the user runs /react-container-presentation-component
• When the user explicitly asks for a React component that follows the Container/Presentation pattern
• When the user wants help deciding or implementing ui vs features classification within the Container/Presentation pattern

Required Questions

If any of the following information is missing, ask the user using ask_user.

1. Component name 2. Type (ui or features) 3. Whether to replace existing components (only when creating ui)

Question requirements:

• Provide the type as options (ui, features)
• Require the component name to be in PascalCase
• For ui, ask whether direct usage of Mantine or other UI libraries in existing features should be replaced with the new component

Procedure

1. Check existing components

• Check whether src/components/ui/<ComponentName> or src/components/features/<ComponentName> already exists.
• If it exists, do not overwrite; confirm the preferred approach with the user.

2. Decide target directory

• ui: src/components/ui/<ComponentName>
• features: src/components/features/<ComponentName>

3. Re-check classification (only when ui is specified)

• Even when ui is specified, before creating files, review Reclassification Rule in references/component-architecture.md.
• If the implementation includes state management, side effects, async processing, context/store updates, or business logic, treat it as features.
• If the result is closer to features, do not proceed as ui; use ask_user and confirm one of the following before continuing.
• Create as features
• Keep ui and move state/logic to parent or features

4. Create required files

• ui: index.tsx, index.module.scss, index.stories.tsx
• features: index.tsx, use<ComponentName>.tsx, presentation.tsx, types.ts, presentation.module.scss, presentation.stories.tsx

5. Replace existing usages (only when creating ui)

• Only when the user approves, replace equivalent direct implementations using Mantine or other UI libraries in existing features with the new ui component.

6. Validate

• Run build and lint commands, and ensure both pass; if issues are introduced by newly added or updated files, fix them.
• Follow Storybook Minimum in references/component-architecture.md for story state decisions.
• Ask the user via ask_user whether to run a Storybook check (for example: "Run" / "Skip for now").
• Run npm run storybook only if the user selects "Run".
• If the user selects "Skip for now", explicitly mention in the final report that Storybook execution was skipped.

Output Contract

• Report the list of files created.
• If replacements were performed, report the list of changed files and replacement details.
• Provide one usage example of the created component.
• Report whether Storybook verification was executed (run/skip), and if run, include the command used.
• Explain why the component was classified as ui or features.
• Summarize where state, side effects, and rendering responsibilities were placed.
• Confirm whether there were any dependency direction violations.
• Clearly state any unresolved items.

Component Architecture Reference

This reference defines classification, file layout, and dependency direction in src/components.

Design Intent and Principles

The goal of this skill is not only to add React components, but to apply the Container/Presentation pattern consistently with clear separation of responsibilities and dependency direction.

This reference does not define full application-wide architecture. It focuses on design quality at the component boundary.

• Separate rendering responsibilities from logic responsibilities.
• Do not place state management, side effects, or business decisions in the presentation layer.
• Avoid mixing responsibilities across boundaries and keep dependency direction explicit.

Classification

• Place all components under src/components.
• Use only two categories:
• ui: render-only, stateless components.
• features: components that include logic.

Reclassification Rule

If the user requests ui but the implementation contains any of the following, treat it as features and ask for confirmation before creating files:

• useState, useReducer, or useEffect.
• Async behavior (API calls, timers, subscriptions).
• Reading from or writing to context/store.
• Business/data transformation logic.

Ask using these options:

• Create as features
• Keep ui and move logic/state to parent or features

Layer Responsibilities

This skill defines layers in two stages.

1. Component Type Layer

2. Internal Layer in features

Notes:

• ui is composed of presentation only.
• features must separate container and presentation.

Implementation Rules

ui

• Keep components stateless.
• Accept data and callbacks via props.
• Do not add side effects or data fetching.
• Prefer primitives from Mantine or other UI libraries first; use custom JSX/SCSS only when needed.

features

• Use the Container/Presentation pattern.
• Keep logic in use<ComponentName>.tsx.
• Follow Container/Presentation Separation Rules (Anti-patterns and Decision Examples) below for detailed responsibility boundaries and anti-patterns.

Container/Presentation Separation Rules (Anti-patterns and Decision Examples)

Principles:

• Container is responsible for state management, side effects, event interpretation, and async processing.
• Presentation is responsible only for rendering from received props.
• Keep business decisions and data transformation in container-side code, not in presentation.

Placement rules:

• Place in container: useState / useReducer / useEffect, API calls, context/store read-write, business rule application.
• Place in presentation: JSX rendering and display-only branching (for example: empty, loading, error views).
• Use types.ts to define I/O contracts between container and presentation.

Anti-patterns:

• Calling APIs or mutations from presentation.
• Updating context/store directly from presentation.
• Implementing business decisions (authorization checks, state transition decisions, data shaping) in presentation.
• Splitting files formally while keeping practical logic in presentation.

Good / Bad examples:

• Bad: presentation.tsx fetches data and manages loading state directly.
• Good: use<ComponentName>.tsx manages data fetching and state, and presentation.tsx renders only from props such as isLoading, items, and onAction.

Dependency Direction

• features -> ui: allowed.
• ui -> features: forbidden.

File Structure

ui

• index.tsx
• presentation.tsx
• presentation.stories.tsx
• presentation.module.scss

features

• index.tsx
• use<ComponentName>.tsx
• presentation.tsx
• types.ts
• presentation.stories.tsx
• presentation.module.scss

Storybook Minimum

• Always create Default.
• Add state-specific stories only when distinct states exist.
• Prefer story sets based on behavior:
• Interactive controls: Hover.
• Input-like: Focus, Error, Disabled.
• Layout/open-close: Open, Closed, Empty.

TypeScript and SCSS Rules Reference

TypeScript Rules

• Do not use any.

  // Bad
  const handler = (e: any) => {};

  // Good
  const handler = (e: React.ChangeEvent<HTMLInputElement>) => {};

• Use type for props instead of interface.

  // Bad
  interface ButtonProps {
    label: string;
  }

  // Good
  type ButtonProps = { label: string };

• Explicitly annotate function return types.

  // Bad
  const getLabel = () => "hello";

  // Good
  const getLabel = (): string => "hello";

SCSS Rules

Tokens

• Use color variables from src/styles/theme.scss.
• Use animation variables from src/styles/animation.scss.
• Define z-index tokens in src/styles/z-index.scss and consume those tokens in component styles.
• In component SCSS, do not hardcode z-index values (for example, avoid z-index: 10; and use a z-index token instead).

Style Constraints

• Prefer Mantine or other UI libraries first; use SCSS only when complementing library styles is necessary.
• Do not use negative margins.
• Prefer unitless line-height.
• Prefer letter-spacing in em.
• When margin is needed, only margin-top and margin-left are allowed.
• Do not set margin or position on root elements.
• The numeric values inside src/styles/z-index.scss must follow a 50-step scale (100, 150, ...).