Redux & Redux Toolkit
/Advanced
State Design Patterns
Definition
Best practices for architecting the 'shape' of your Redux store to ensure scalability and maintainability.
Explain Like I'm New
Don't just dump variables into Redux randomly. Group them by 'Feature' (e.g., Auth, Cart, Users) or by 'Domain'. Keep your state as flat as possible. Treat your Redux store like a database, not a trash can.
Real World Example
Separating 'UI State' (is the sidebar open?) from 'Data State' (what is the list of users from the server?).
Common Use Cases
- •Architecting enterprise applications
Terminal Output
bash / terminal
/*
Great State Design Principles:
1. Avoid redundant data. (If you have a list of items, don't store
'numberOfItems: 5'. Just use items.length in your selector).
2. Keep state flat (Normalization).
3. Treat Redux as a cache for server data.
4. Slices should correspond to domains (e.g., 'auth', 'products'),
not UI pages (e.g., 'homePage', 'settingsPage').
*/
Interview Questions
basic
- Should you design your state tree based on your UI components or your underlying data?
intermediate
- What is the 'Ducks' pattern?