Questions
3 of 13
11. How do you configure a store in Redux Toolkit?
22. What is the purpose of configureStore()?
33. How does configureStore() differ from Redux’s createStore()?
44. What are the default middlewares included in Redux Toolkit?
55. How do you add custom middleware to the store?
66. How do you integrate multiple slices into one store?
77. What is the role of the root reducer?
88. What is the default devtool configuration in Redux Toolkit?
99. How do you integrate RTK Query’s API reducer into the store?
1010. How can you add persistence (e.g., Redux Persist) to the store?
1111. How do you use TypeScript with the store setup?
1212. How do you test a store configuration?
1313. What is the difference between store enhancers and middleware?
RTKRTK
Basics
Slice
Actions
Reducers
RTK Query
Store
Thunk
Scenario Based
03 / 13

3. How does configureStore() differ from Redux’s createStore()?

Difference Between configureStore() and createStore()

While both configureStore() and createStore() are used to create a Redux store, configureStore() from Redux Toolkit provides a simpler, safer, and more efficient setup compared to Redux’s traditional createStore() method.

Key Differences
  1. 1

    1. Boilerplate Reduction: configureStore() automatically sets up middleware, DevTools, and enhancers, while createStore() requires manual setup.

  2. 2

    2. Default Middleware: configureStore() includes redux-thunk and checks for common issues like accidental state mutations; createStore() includes none by default.

  3. 3

    3. DevTools Integration: Redux DevTools are automatically enabled in configureStore(), but must be manually configured in createStore().

  4. 4

    4. Middleware Composition: In configureStore(), you can easily extend middleware via getDefaultMiddleware(), while in createStore() you must use applyMiddleware() manually.

  5. 5

    5. Better Type Safety: configureStore() provides built-in TypeScript support and typed dispatch and state, unlike createStore().

Example: Using configureStore() vs createStore()

The configureStore() approach simplifies setup and enforces best practices out of the box, while createStore() requires manual configuration for even basic features like middleware and DevTools.

Advantages of configureStore()
  1. 1

    - Cleaner Setup: Minimal configuration required to get started.

  2. 2

    - Built-in Safety: Middleware detects accidental state mutations and non-serializable values.

  3. 3

    - Developer Friendly: Automatically connects to Redux DevTools and supports RTK Query integration.

  4. 4

    - Modern Standard: Recommended approach in all Redux Toolkit-based projects.

In summary, configureStore() is a modern replacement for createStore() that emphasizes simplicity, safety, and developer experience.

Difficulty: 5/10
Topics: store setup, middleware, devtools

Scenario Questions

0-2 years experience
  1. 1

    You need to add Redux DevTools to a new React app. How would you set up the store using configureStore versus createStore?

  2. 2

    If you call configureStore without specifying middleware, what middleware does RTK include by default?

  3. 3

    You have a simple counter slice. Show the code to create the store with configureStore and compare its length to using createStore.

2-5 years experience
  1. 1

    Your team upgraded from Redux to RTK, but after switching to configureStore some async thunks stopped dispatching actions. What could cause this and how would you debug it?

  2. 2

    When adding a custom logger middleware, why might you need to use getDefaultMiddleware in configureStore but not when using createStore?

  3. 3

    Explain why a feature that relied on manually applying thunk middleware with createStore broke after moving to configureStore.

5-8 years experience
  1. 1

    In a large codebase you need to integrate multiple feature slices, each with its own middleware and preloaded state. How does configureStore help you manage this compared to manually composing createStore, and what trade‑offs should you consider for performance and testability?

  2. 2

    Your application experiences a memory leak after hot‑reloading stores in development. How would you investigate whether configureStore’s default middleware setup contributes, and what adjustments would you make?

  3. 3

    Design a pattern for dynamically injecting reducers at runtime. Compare how you would implement this with configureStore versus a custom createStore solution.

8+ years experience
  1. 1

    Your organization is migrating 15 micro‑frontends from legacy createStore setups to a shared RTK configureStore pattern. What architectural guidelines would you establish to ensure consistency, avoid duplicated middleware, and support independent deployment?

  2. 2

    Discuss the long‑term maintenance implications of using configureStore’s built‑in devtools and immutable checks in production across multiple teams. How would you decide when to disable them?

  3. 3

    If you need to support both a legacy code path that still uses createStore and a new path using configureStore, how would you design an abstraction layer to minimize friction and future migration risk?

Follow-up Questions

  • ❓What would happen if you called configureStore but manually added thunk again?
  • ❓How do you disable the immutable‑state check in production?
  • ❓Can you describe how you’d unit‑test a store created with configureStore?