skill-frontend-component-engineering

Implements stateful frontend components with explicit state ownership and async transition handling.

Updated Apr 9, 2026
One-click install
npx skills add https://github.com/longdang193/project-OS-starter --skill skill-frontend-component-engineering-longdang193
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: skill-frontend-component-engineering
Source: https://github.com/longdang193/project-OS-starter/tree/main/generated_agents/claude/skills/skill-frontend-component-engineering
Command: npx skills add https://github.com/longdang193/project-OS-starter --skill skill-frontend-component-engineering-longdang193

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Stateful frontend components often accumulate duplicated state, unclear ownership, and broken async behavior such as missing rollback or duplicate submissions. This Skill provides a decision method for component boundaries, state ownership, URL state, server data, and asynchronous UI transitions. ## Core Features & Use Cases - State Ownership Decisions: Assigns each state value a single owner across local state, shared ancestors, URL parameters, server-state caches, context, or global stores. - Async Transition Modeling: Covers pending, success, empty, error, retry, cancellation, stale data, and duplicate submission states before implementation. - Optimistic Mutation Control: Applies optimistic updates only for reversible actions with snapshot-based rollback and server reconciliation. - Use Case: When building a searchable table whose filters, sort, and pagination must survive refresh and be shareable, this Skill guides you to use validated URL search parameters as the single state owner instead of mirroring state into useState or a global store. ## Quick Start Use this skill to design the component structure and state ownership for a data-backed page with shareable filters and optimistic mutations.

Frequently Asked Questions about skill-frontend-component-engineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where frontend state should live?▼

Choose the nearest native owner that satisfies the behavior: local state for component-only interaction, nearest shared ancestor for sibling coordination, URL state for shareable navigation state, server-state cache for remote data, and context for stable cross-tree dependencies.

When should I use URL state instead of useState?▼

Use URL state when the state must be shareable, refresh-safe, and Back/Forward-aware, such as filters, sort, page, and tabs. Do not mirror URL parameters into useState, local storage, context, or a global store.

How do I implement optimistic updates safely in React?▼

Use optimistic updates only when the action is reversible and previous state can be restored. Snapshot the smallest affected state so rollback does not overwrite unrelated work, then reconcile with canonical server state after settlement.

When should I split a component into container and presentation layers?▼

Separate data orchestration from presentation only when mixing them obscures failure behavior, reuse, or testing. Do not create container components by default or split components by file length alone.

When should I avoid using this component engineering approach?▼

Skip it for copy-only changes, isolated styling, or simple presentational components with obvious props. The method targets stateful components, data-backed pages, and client/server state decisions.