一键导入
state-management-patterns
When deciding where and how to store data in a modern web application.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
When deciding where and how to store data in a modern web application.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
When improving read performance and reducing database load.
When designing loosely coupled systems that react to state changes asynchronously.
When setting up telemetry, debugging distributed systems, or standardizing application output.
When creating or extending an HTTP API for client consumption.
When addressing slow application endpoints, high database CPU usage, or standardizing data access patterns.
When designing how a system recovers from and reports failures.
| name | state-management-patterns |
| description | When deciding where and how to store data in a modern web application. |
| version | 2.0.0 |
| category | frontend |
| tags | ["frontend","state","architecture"] |
| skill_type | architecture |
| author | skiLLM |
| license | MIT |
| compatible_agents | ["claude-code","cursor","copilot","codex"] |
| estimated_context_tokens | 2000 |
| dangerous | false |
| requires_review | false |
| security_level | safe |
| dependencies | ["react-component-design"] |
| triggers | ["state","redux","context","provider","store","hooks"] |
| permissions | {"filesystem":{"read":true,"write":true},"network":{"outbound":false},"shell":{"execute":false}} |
| input_requirements | ["React application","state management code"] |
| output_contract | ["URL-driven state for filters","server cache separation","no state duplication"] |
| failure_conditions | ["attempting to manually sync server data to global store","mirroring props into state"] |
| last_updated | "2026-05-15T00:00:00.000Z" |
Applications suffer from bugs and performance issues when state lives in the wrong place. This skill guides teams to categorize state by its nature (UI, server, URL, global) and store it appropriately, eliminating duplication, excessive re-renders, and synchronization bugs.
useState onlyconst [val, setVal] = useState(props.val) (causes sync bugs)useStateuseState❌ Anti-pattern (Wrong state locations, duplication, mirroring):
// Redux store has everything including UI state
const store = {
filters: { search: '', sort: 'name' }, // WRONG: belongs in URL
users: [...], // OK: server data
isModalOpen: false, // WRONG: UI-only state
theme: 'dark' // OK: truly global
};
// Component mirrors props and stores server data locally
const UserList = ({ searchQuery }) => {
const [search, setSearch] = useState(searchQuery); // ANTI-PATTERN: mirrors props
const [users, setUsers] = useState([]); // ANTI-PATTERN: manual server sync
useEffect(() => {
fetch(`/api/users?q=${search}`)
.then(res => res.json())
.then(data => setUsers(data)); // Manual sync to local state
}, [search]);
return <div>{users.map(u => <p>{u.name}</p>)}</div>;
};
✅ Correct pattern (Proper state separation):
const UserList = () => {
// 1. URL drives state (filters/search)
const [searchParams, setSearchParams] = useSearchParams();
const search = searchParams.get('q') || '';
// 2. Server data via React Query (cached, not Redux)
const { data: users } = useQuery({
queryKey: ['users', search],
queryFn: () => fetch(`/api/users?q=${search}`).then(r => r.json())
});
// 3. UI-only state stays local
const [isModalOpen, setIsModalOpen] = useState(false);
// 4. Global state from Context/Redux
const { theme } = useContext(ThemeContext);
return (
<div>
<input
value={search}
onChange={(e) => setSearchParams({ q: e.target.value })}
/>
<button onClick={() => setIsModalOpen(true)}>Add User</button>
{users?.map(u => <p>{u.name}</p>)}
</div>
);
};