Store Setup
This page covers how to configure your Redux store, set up typed hooks, and organize your project structure.
Folder Structure
Projects MUST follow this structure for consistency and maintainability:
src/
app/
store.ts # Store configuration
hooks.ts # Typed hooks (useAppDispatch/useAppSelector)
shared/
types/ # DTOs (API), Domain models, mappers
utils/ # Shared utilities
services/
client.ts # RTK Query base client
baseQuery.ts # Base query with auth/chainId/retry
features/
user/
user.client.ts # RTK Query endpoints
user.slice.ts # UI state slice
user.selectors.ts # Memoized selectors
__tests__/ # Tests
land/
land.client.ts
land.slice.ts
land.selectors.ts
credits/
credits.client.ts
credits.slice.ts
credits.selectors.tsFolder Organization Principles
Feature-based - Group by business domain, not technical role
Co-location - Keep related code together
Clear separation - Distinguish between remote data (
.client.ts) and local state (.slice.ts)
Store Configuration
The store MUST be configured with RTK's configureStore and include all necessary middleware.
Basic Store Setup
Configuration Options
Serializable Check
The serializableCheck middleware validates that all state is serializable. Configure it to ignore known exceptions:
Never disable serializableCheck entirely. Instead, configure exceptions and keep non-serializable data outside Redux.
Dev Tools
Enable Redux DevTools in development for debugging:
For production debugging (if needed), use specific configuration:
Typed Hooks
Create typed versions of useDispatch and useSelector for better type inference and developer experience.
Hook Setup
Usage in Components
Benefits of Typed Hooks
Autocomplete - Full IntelliSense for state shape
Type Safety - Catch errors at compile time
Refactoring - Rename state properties with confidence
Less Boilerplate - No need to specify
RootStaterepeatedly
Provider Setup
Wrap your app with the Redux Provider:
Next.js App Router
Next.js Pages Router
React (Vite/CRA)
Environment Configuration
Configure environment-specific settings:
Type Definitions
Create shared type definitions for consistency:
Multiple Store Instances
For testing or micro-frontends, you may need multiple store instances:
Best Practices
1. Single Store
Always use a single store instance per application:
2. Lazy Loading Reducers
For code splitting, inject reducers dynamically:
3. Hot Module Replacement
Enable HMR for reducers in development:
4. State Persistence
When using redux-persist, configure carefully:
Next Steps
Learn about RTK Query for data fetching
Understand State Management for local state
Review Component Patterns for usage examples
Last updated