state-management-patterns
Skill6 starsChanged 6 months agoMITView on GitHub
When deciding where and how to store data in a modern web application.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- farming-labs/fm-skillstheir own version, first seen Mar 14, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- farming-labs/fm-skills★ 35same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- caching-strategiesSkill
- event-driven-designSkill
- logging-observability-standardsSkill
- api-design-restSkill
- database-query-optimizationSkill
- error-handling-architectureSkill
- code-review-guidelinesSkill
- ci-cd-pipeline-architectureSkill
- debugging-strategiesSkill
- git-workflow-branchingSkill
- dom-security-hardeningSkill
- react-component-designSkill
- accessibility-ui-designSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 10 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 52
Separate Server Cache: Use React Query / SWR / Tanstack Query for ALL server data (never Redux)
- Very specific: line 53
Localize UI State: Keep form inputs, modals, toggles, tooltips in component useState only
- Distinctive: line 54
Identify Global: ONLY theme, auth, and language user preferences go to Context/Redux
- Distinctive: line 56
Verify Sync: Ensure no state is duplicated across layers
- Distinctive: line 59
MUST store shareable states (filters, search, pagination) in URL, not Redux/Context
- Distinctive: line 60
MUST use React Query/SWR for server data, NEVER Redux
- Distinctive: line 61
MUST NOT manually sync server data between global store and cache layer
- Distinctive: line 62
MUST NOT store UI-only state (modal open, form focus) in global store
- Distinctive: line 63
MUST NOT mirror props into local state
- Distinctive: line 64
MUST NOT have duplicate copies of state
- Distinctive: line 77
Search/filter parameters not reflected in URL
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
State Management Patterns
Purpose
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.
When to use
- Adding new interactive features that require data persistence across views
- Refactoring an app suffering from excessive re-renders
- Integrating external data fetching with local UI state
- Deciding where a new piece of state should live
- Migrating from Redux/global store when unnecessary
When NOT to use
- Component-level prop decisions (use React Component Design skill)
- Server caching strategy decisions (use Caching Strategies skill)
- Real-time synchronization protocols (different concern)
Inputs required
- Existing React application with state management code
- Understanding of current state locations (Redux, Context, useState)
- List of state mutations and their trigger sources
Workflow
- Categorize State: Classify each state piece as: UI-only, Server, URL-driven, or Truly Global
- URL First: Move ALL sort, filter, pagination, search, and tab parameters to URL search params
- Separate Server Cache: Use React Query / SWR / Tanstack Query for ALL server data (never Redux)
- Localize UI State: Keep form inputs, modals, toggles, tooltips in component
useStateonly - Identify Global: ONLY theme, auth, and language user preferences go to Context/Redux
- Implement Separation: Refactor code to respect these boundaries
- Verify Sync: Ensure no state is duplicated across layers
Rules
- MUST store shareable states (filters, search, pagination) in URL, not Redux/Context
- MUST use React Query/SWR for server data, NEVER Redux
- MUST NOT manually sync server data between global store and cache layer
- MUST NOT store UI-only state (modal open, form focus) in global store
- MUST NOT mirror props into local state
- MUST NOT have duplicate copies of state
Anti-patterns
- Mirroring State:
const [val, setVal] = useState(props.val)(causes sync bugs) - Global Everything: Redux store bloated with UI toggles and temporary form data
- Manual Server Sync: Fetching data and manually updating Redux instead of using React Query
- URL-less Navigation: Using only React Router state for filters/search instead of URL params
- Inverted Cache: Using Redux as the source of truth for server data instead of cache layer
Failure conditions
- Attempting to manually sync server data to global store
- UI-only state (modals, toggles) stored in Redux
- State duplication across URL, cache, and store
- Search/filter parameters not reflected in URL
Validation checklist
- All shareable states (filters, search) are in URL search params
- Server data is fetched via React Query / SWR, not Redux
- No manual synchronization between global store and cache layer
- UI-only state (modals, tooltips, focus) is in component
useState - Global store contains ONLY: auth, theme, language, user preferences
- No prop-value mirroring in
useState - URL parameters drive filtering/sorting in data display
- Back button behavior works correctly with filter/search state
Output format
- Code structure: Separate imports for URL hooks, server cache hooks, and Context providers
- File organization: State logic in custom hooks, not component bodies
- API shape: URL params in component mount, server cache managed by React Query
- Validation: Backward-compatible URL parameter parsing with defaults
Security considerations
- URL state MUST be validated/sanitized before use (filter injection)
- Sensitive data (auth tokens, PII) MUST NEVER be in URL
- Server cache MUST respect user permissions before caching
- Global store credentials MUST be HttpOnly/secure if stored
Agent execution notes
- Agent MAY: Refactor state to new locations, create custom hooks for state logic, migrate Redux to React Query
- Agent MUST NEVER: Store auth tokens in URL, put sensitive PII in URL, manually sync server cache
- Agent MUST ASK: Before deleting Redux/Context entirely, before moving state to global store
- Agent MUST VALIDATE: URL state validated, no state duplication, React Query properly configured
Example
❌ 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>
);
};Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

