Coder Legion - Recent posts tagged redux

Redux Refactoring Playbook: From Action-Types Soup to RTK Query — Without Rewriting the App

Thu, 29 Oct 2026 08:51:02 +0000

Every React codebase of a certain age has one: the legacy Redux store. Hundreds of thunk actions, manually managed loading flags, per-feature cache invalidation, and a polling timer per data type pulling the full payload whether anything changed or not.

Ours lived under a real-time monitoring dashboard tracking 1,000+ GSM installations at Orange Romania — and by the time we migrated to RTK Query, the story ended with dashboard responsiveness up ~40%, telemetry traffic down 20%, and "frozen dashboard" complaints down 30%.

The previous article told that performance story. This one is the refactoring mechanics: in what order things moved, which decisions unlocked the next one, and the one rule that made a no-rewrite migration possible.

Rule 1 — Strangle, don't rewrite

The store wasn't broken in one place; it was broken everywhere: a switch-case reducer file nobody fully read, five middleware, isLoading / isRefreshing / hasError flag families per resource, and component-level useEffect chains firing fetches in a specific order "because it worked."

A big-bang rewrite was a non-starter: the dashboard was used every day by operations teams. So the rule was:

One page migrates per PR. The rest of the app keeps running on the legacy store untouched.

Redux makes this possible because combineReducers is natural strangler scaffolding:

const rootReducer = combineReducers({
  // new pages live here
  ordersApi: ordersApi.reducer,          // RTK Query
  invoices: invoicesSlice.reducer,       // RTK slice
  // legacy pages keep their ducks until their turn
  legacyTelemetry: legacyTelemetryReducer, // switch-case reducer, retired last
});

Each migration PR carried its own before/after render counts and INP p75 from a fixed scripted interaction. If the numbers moved the wrong way, the PR didn't merge — refactoring without a measurement loop is just rewriting with extra steps.

The code was the easy half. The pitch mattered as much: I sold this as risk control, not cleanup. Every PR shippable alone meant no feature-freeze window that anyone had to buy; the cost I did have to name up front was the parallel-store tax: two stores side by side meant duplicated fixtures and slower reviews while a slice waited for its turn. Leadership signed off because every migration PR ended with a measurement, not with the word "done". One more org-side lesson: the change-flag contract needed a backend buy-in, and I opened that conversation politely, late. Open it on day one; that delay cost us a month.

Rule 2 — Selectors are the API. Freeze them first.

The trick that removed 90% of the migration risk: components never touched state shapes directly.

The legacy store had selector functions (selectOrders, selectNodeById, selectIsNodeActive). Before migrating anything, we froze them as the contract and then made each selector a re-export shim that could source data from either world:

// selectors/orders.js
import { legacyOrders } from './legacySelectors';
import { useGetOrdersQuery } from '../api/ordersApi';

export function useOrders(selector) {
  const { data, isFetching } = useGetOrdersQuery();
  // legacy pages keep working against the same contract
  return useMemo(() => selector(data ?? legacyOrders()), [data, selector]);
}

(Simplified — the real shims carried fallbacks during the window when a page's data half-lived in the old store. The point is the shape: the component-facing API never moved, only its plumbing did.)

Result: a "migration PR" changed the data layer under a page, not forty components over it. That made page-by-page migration realistic rather than a nice idea.

Rule 3 — Kill loading flags with RTK Query, not with better thunks

There was a middle step available: keep the thunks and clean them up. I'd have kept every race. Request A finishing after request B silently overwrote fresher data, and that was our most common production bug, because each flag family carried its own private version of it.

So server state moved into RTK Query, and components declare what they need, not how to fetch it:

// before: every call site, every page
dispatch(fetchOrders());
// + component-local: isLoading, ordersError, lastRefreshed...

// after: the component declares the requirement
const { data: orders, isLoading } = useGetOrdersQuery(undefined, {
  pollingInterval: 0, // see Rule 4 — we don't poll blindly
});

Seventeen loading-flag families disappeared in this step. After it, a component tracking its own fetch lifecycle existed in exactly one place: a page that legitimately needed manual control.

Rule 4 — Polling moves from timers to tags

Old polling: one setInterval per data type, full payload every tick. On a dashboard watching 1,000+ nodes, that's thousands of identical requests an hour and constant re-render churn over data that hadn't changed.

New polling is no polling — it's a change-flag endpoint: a ten-byte version string the dashbo
ard polls on a timer, and the real data refetches when that string actually changes.

export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  tagTypes: ['Nodes'],
  endpoints: (build) => ({
    nodesChanged: build.query<{ version: string }, void>({
      query: () => 'nodes/changed',       // returns a version string only
    }),
    getNodes: build.query<NodeState[], void>({
      query: () => 'nodes',
      providesTags: ['Nodes'],
    }),
    // refetch tagged data only when the flag version changes:
    // a listener middleware polls `nodesChanged` (cheap, ~10 lines) and,
    // on version change, dispatches api.util.invalidateTags(['Nodes'])
  }),
});

const flagListener = createListenerMiddleware();

flagListener.startListening({
  predicate: (action, currentState, previousState) => {
    // the version lives in RTK Query's own cache, so the store
    // snapshot gives us both "current" and "what it used to be"
    const cur = nodesChanged.select()(currentState)?.data;
    const prev = nodesChanged.select()(previousState)?.data;
    return cur != null && cur !== prev;
  },
  effect: (action, api) => {
    api.dispatch(api.util.invalidateTags(['Nodes']));
  },
});

// the flag endpoint itself: cheap on purpose
//   query: () => 'nodes/changed',   // returns ~10 bytes: a version string
//   pollingInterval: 5000,

What happens on an update, end to end: the version goes into the cache and
predicate sees it differ from the previous snapshot, invalidateTags marks
every tagged entry stale without removing it (the screen keeps the old
data), mounted subscribers immediately refetch — deduplicated to one request
per endpoint+args no matter how many components listen — and one re-render
lands the new data. A component sees isLoading: false, isFetching: true
during that window, which is why nothing flashes. If the flag endpoint dies,
data simply goes stale until the next successful tick; nothing breaks. If
nodes changed five times between two ticks, one refetch covers it: the
version is a snapshot of "what is true now", not an event queue.

What stayed in Redux core

A mistake we avoided (mostly): RTK Query is for server state only. UI-owned state — selected node, filter panel state, column layout, wizard steps — stayed in plain createSlice. Migrating that into queries would have replaced a working pattern with a worse one.

The end state: slices for decisions, RTK Query for data, zero custom cache code, zero hand-rolled loading flags.

The honest ledger

From the published case, measured as perceived dashboard responsiveness (how fast fresh data lands after a change, without UI-thread churn):

Dashboard responsiveness: +~40%
"Frozen dashboard" complaints: −30%
REST telemetry traffic: −20%

What I can't give you is a LOC table with a precise count — we deleted more code than we wrote every migration PR, and by the end the store directory had visibly halved; I kept no exact tally, and a made-up precision here would be dishonest.

What I'd do differently

Start with RTK Query for any new page. Half the migration tail was legacy thunks for features that could have been endpoints from day one.
Freeze selectors before touching anything. The component-facing API is the migration's unit of safety.
Measure per PR, not per epic. The scripted interaction + INP check cost minutes per PR and caught two regressions a "it looks fine" test never would.
Write the change-flag backend contract early. The polling redesign was the single biggest win and it needed a backend buy-in — politeness about it cost us a month.

Your refactoring checklist

Inventory actions/thunks/loading flags — count them, this is your "before" baseline.
Freeze selectors as the component-facing contract.
Add RTK Query via combineReducers alongside the legacy store.
Migrate one page per PR; measure INP p75 + render count on a fixed interaction.
Server state → endpoints with tags; UI state stays in slices.
Replace timers with a change-flag contract before touching fetch logic.
Delete: action-type strings, flag families, custom cache code. The deletion count is the score.

The performance numbers come from the same production system as my earlier piece, A 40% Faster Fault-Detection Pipeline Without WebSockets — that one tells the polling-protocol story; this is the data-layer refactoring around it.

The Code You Ship Today Will Be Read By Someone Who Wasn't In The Room

Sun, 21 Jun 2026 17:36:19 +0000

This is not an article for juniors excited about the latest React ecosystem drop.

This is for the senior who's inheriting a codebase, the CTO deciding what stack the next five years run on, and the tech lead who has to explain to a new hire why nothing is where they expect it to be.

The frontend industry has spent the last four years selling "simplicity." What it actually shipped was complexity with better branding — and the bill comes due the moment the original author leaves the room.

I've been that original author. And I've been the person inheriting the codebase six months later. The experience is very different depending on which tools were used.

This article came from a mistake I made on my own project. I followed the hype — tried RTK Query, then React Query alongside Redux. At some point I found myself pulling isLoading from Redux while data lived in React Query cache. Two systems coordinating inside one component. One updating the other. No single place to look at and understand what was happening. That's when I stopped and asked why I was doing this to myself.

When The Owner Changes, The Code Becomes A Pumpkin

Every architectural decision has two phases: the day you write it, and every day after that when someone else has to read it.

The libraries being pushed hardest right now — RTK Query, TanStack Query, and their associated patterns — are optimized entirely for phase one. Fast to write. Minimal ceremony. Feels clean in a greenfield project with the original author at the keyboard.

Then someone leaves. Or you come back after six months. Or a new senior joins and spends their first two weeks asking "where does this data actually come from?"

Now you find out what your architecture is really worth.

`store/gamesState.ts` Is A Contract

Here's what a Redux store file actually is: a singleton. One file. One source of truth. Immutable state, pure transitions. Every piece of state your application can be in is described there, and every action that causes a transition is explicit and named.

Any developer — regardless of whether they were on the team when it was written — can open store/gamesState.ts and read it like a specification:

// This is not boilerplate. This is documentation.
case FETCH_GAMES_SUCCESS:
  return {
    ...state,
    items: action.payload.games,
    total: action.payload.total,
    isLoading: false,
  };

What caused this state? FETCH_GAMES_SUCCESS. What changed? Exactly these fields. What was it before? Open DevTools, click the action, read the diff.

This is not a legacy pattern. This is explicit state as specification. The "boilerplate" everyone complained about was load-bearing. It forced developers to name their intentions, describe their transitions, and put business logic somewhere findable.

When you replace this with hooks and cache keys, you don't remove the complexity. You distribute it across the component tree where it has no address.

It Even Has A Name. Several, Actually.

The architecture I'm describing — thunk + reducer + selector + container + representation component — isn't just a pattern that feels right. It maps directly onto SOLID principles. Not as a coincidence, but because it was designed around the same ideas.

Single Responsibility is the most obvious one. Each layer does exactly one thing:

The thunk handles the API call and hides the HTTP details;
The reducer owns state transitions — nothing else;
The selector projects state into exactly what the component needs;
The container connects the store to the component;
The representation component renders.
You can open any one of these files and know immediately what it's responsible for. That's not an accident.

Open/Closed follows naturally. You add a new action without touching existing reducers that don't care about it. You add a new selector without modifying any component. You extend the system by adding, not by modifying. The existing, tested code stays untouched.

Dependency Inversion is where it gets interesting. The representation component doesn't know where its data comes from — it receives props and renders. The container depends on selectors and dispatch, not on fetch or axios or any specific API implementation. The thunk hides the entire HTTP layer behind an action creator. Every layer depends on abstractions, not on concrete implementations. Swap your HTTP client, change your API shape, refactor your backend response — the components don't care.

With React Query, the component imports useQuery, calls a specific query function, and is now directly coupled to the data fetching layer. The dependency arrow points the wrong way, business logic is not encapsulated. SOLID 101.

None of this is theoretical. These principles exist because codebases need to be maintained by people who weren't there when it was written. Redux + thunk enforces them structurally. React Query leaves them as an exercise for the reader.

The Testing Argument Nobody Makes

Want to test every possible UI state your application can render?

With Redux: create a store factory, inject any state you want, render the component. Done. You can test loading states, error states, empty states, partial states, race conditions — all without a running backend, without mocking fetch, without coordinating multiple hooks.

// Test any UI state in three lines
const store = createTestStore({ games: { items: [], isLoading: true } });
render(<GameList />, { store });
expect(screen.getByTestId('skeleton')).toBeInTheDocument();

The same store factory works in Storybook. You want to visually develop a component in a specific state? Pass the store. Every permutation is reproducible, shareable, and documented in your story file.

This matters most in applications where state transitions carry real business weight — dashboards, e-commerce flows, multi-step purchase funnels. Consider a checkout widget that has to handle: items in cart, discount applied, payment processing, payment failed, retry pending, order confirmed. Each of these is a distinct UI state that a developer needs to build, a designer needs to review, and a QA engineer needs to verify independently.

With a store factory, each state is a named, reproducible fixture:

createTestStore({ checkout: cartWithDiscount });
createTestStore({ checkout: paymentProcessing });
createTestStore({ checkout: paymentFailed });
createTestStore({ checkout: orderConfirmed });

A developer can build and test each stage in isolation without completing an actual purchase. A designer can review every edge case in Storybook without touching a staging environment. QA can write a deterministic test for the "payment failed → retry" transition without timing their assertions around network requests.

With React Query, you are simulating a sequence of network responses to arrive at a UI state that Redux can simply declare. The test becomes an integration test whether you want it to be or not.

Can React Query do this? Not cleanly. You're mocking fetch, intercepting network requests, or wrapping components in QueryClientProvider with pre-seeded cache — and then praying the cache hydration timing doesn't introduce flakiness. The test setup becomes an archaeology project.

Moreover, backend data is not UI state. It's a remote resource your UI happens to display. When you treat API responses as state, you couple your component layer to the network contract — and when that contract changes, your UI logic changes with it.

The store as a factory for UI states is one of the most underrated architectural advantages of Redux, and it's never mentioned in the articles declaring Redux dead.

Your QA Team Had A Superpower And You Took It Away

Redux DevTools lets you export the complete state of an application at any point in time — every action, in order, with the state diff after each one — as a JSON file.

When a tester found a bug, they exported the log and sent it to the developer. The developer imported it, time-travelled to the exact moment of failure, and reproduced the bug deterministically. No "I can't reproduce it." No guessing at sequences. No "works on my machine."

I've worked on teams where QA did exactly this. A tester would export the DevTools log, drop it in Slack, and by the time you opened it you already knew what happened. That's not a workflow you appreciate until it's gone.

What does your debugging workflow look like with React Query? You have a snapshot of the current cache. No history. No sequence. No "what state was the application in when this happened." When a bug depends on the order of requests, a race condition between a cache invalidation and a component mount, or a stale closure over a query key — you are on your own.

I've debugged these. They take days, not hours. And every time, the fix was straightforward once you actually understood what happened — which was the hard part.

The Caching Myth

The primary selling point of React Query is client-side caching. Fetch the data once, serve it from cache, background-revalidate when stale.

Here's the thing: your backend already has Redis. Your HTTP layer already has Cache-Control, ETag, and Last-Modified. These mechanisms are decades old, battle-tested, and work for every client simultaneously — browser, mobile, service worker, another backend service.

Client-side caching with React Query is consistent only per-tab, per-user, per-session. Two users looking at the same data can see different things. Two tabs in the same browser can diverge by default — cross-tab sync requires additional configuration. Invalidation is manual and per-endpoint.

If your backend API response is slow enough that client-side caching measurably improves your application, the correct fix is Cache-Control: max-age=300 on the API response, or a Redis layer in front of the slow query. Both solutions are simpler, more consistent, and cover more clients than a JavaScript caching library.

Client-side caching in a library is a solution to a backend problem. It became popular because it's easier to install an npm package than to convince your backend team to add cache headers. That's a political solution masquerading as a technical one.

And if you're hitting a third-party API you don't control — the answer is a backend gateway, not a JavaScript cache. You get Redis, hidden credentials, rate limiting, and response transformation in one place. The frontend still gets clean HTTP headers. The frontend shouldn't know the third-party API exists at all.

Two Mental Models Is Not Separation Of Concerns

The recommended pattern for "doing Redux and React Query correctly" is: React Query owns server state, Redux owns client state. Sounds clean. In practice:

// "Clean separation"
const selectedId = useSelector(s => s.ui.selectedGameId);  // Redux
const { data: game } = useQuery({                           // React Query
  queryKey: ['game', selectedId],
  queryFn: () => fetchGame(selectedId),
  enabled: !!selectedId,                                    // coordination between systems
});

Now you have two systems that need to know about each other. Redux feeds React Query a key. React Query refetches when the key changes. But what happens when the Redux state updates before the query refetches? What if the component remounts during a background refetch? What if enabled flips to false mid-request?

These are not edge cases. These are the normal conditions of a real application under normal user behavior. And when they go wrong, you are debugging two systems simultaneously with two different DevTools that don't share a timeline.

This isn't separation of concerns. It's multiplication of cognitive load. You're not choosing the right tool for each job — you're managing a coordination problem you created by splitting one job across two tools.

One system. One DevTools. One data flow from request to render. The complexity is real either way — the question is whether it's concentrated somewhere readable or distributed somewhere invisible.

Boilerplate That Describes Business Logic Is A Specification

The core argument against Redux was always the boilerplate. Four files per feature. Action type constants. Explicit reducers for every transition.

Here's what that argument misses: boilerplate that describes business logic is not boilerplate. It is a specification.

FETCH_GAMES_REQUEST, FETCH_GAMES_SUCCESS, FETCH_GAMES_FAILURE are not ceremony. They are the named states of a business operation, written once, readable forever. The reducer that handles them is not repetitive noise — it is the documented contract of what your application does with data.

When you eliminate this in favor of a useQuery hook that manages its own internal state machine invisibly, you didn't remove the complexity. You moved it inside a library where it has no name, no address, and no audit trail.

The industry optimized for the experience of writing code. It made writing fast and reading hard. The people who write the code and the people who maintain it are rarely the same people — and they're almost never in the same time zone when the production incident happens at 2 AM.

I've been on both sides of that 2 AM call.

React's Own Premise

There's a principle so fundamental to React that it's easy to forget it's an architectural statement:

UI = f(state)

React's entire model is built on this. You describe what state is, React renders its representation. The component doesn't decide what to show — it reads state and maps it to UI. That's it.

This means state should be the first-class citizen of your architecture. Explicit, addressable, testable in isolation from the network, from components, from rendering. The UI is just the output.

Redux understood this and built the entire model around it. The store is the complete description of what your application is right now. The component reads it and renders. Simple, honest, aligned with how React actually works.

React Query inverts this. State becomes a derivative of network request history — what was fetched, when, and whether it's stale. You're no longer describing what is, you're describing where it came from and when it expires. The UI is now a function of fetch history, not of state.

When your architecture fights the mental model of the framework you're using, you're paying a tax on every component you write. You just don't see it on the invoice until someone else has to read the code.

The Verdict

If you're a CTO choosing a stack: ask yourself which codebase you want to inherit in three years. The one where every state transition is named and traceable, tests are deterministic, QA can export a reproduction case, and any new hire can read the store like documentation — or the one where the data flow lives inside hooks, cache keys, and the institutional memory of developers who have since left.

If you're a senior evaluating your current architecture: the question isn't which library is more modern. The question is what happens to your application's readability the day the original author is unavailable.

And if you're thinking "this only matters for large, complex apps" — there's no such thing as a permanently small project. Either it dies, or it grows. When it grows, you pay for every architectural shortcut taken when it was "just a small app."

Boring, explicit, traceable code outlives clever, minimal, modern code. Every time.

Redux + thunk + reselect. Four files per feature. Named action types. Explicit reducers. Store factory for tests and Storybook. DevTools for QA. It was never broken.

The tools that enforce good architecture through friction aren't legacy. They're honest about what software actually costs.

Artem Trukhanov is a Lead Frontend Engineer with 10+ years of experience in React, TypeScript, and Node.js. Currently building Grimoire — a self-hosted game backlog manager with Steam, PSN & Xbox sync and AI recommendations. trukhanoff.dev

Mastering Redux Toolkit By Building A Shopping Cart

Wed, 19 Nov 2025 21:53:51 +0000

Introduction

Redux Toolkit (RTK) is the official, recommended way to write Redux logic.
It was designed to fix the long-standing complaints developers had about Redux:

Redux was too “boilerplate-heavy”
Setting up a store was complicated
Writing reducers with switch statements felt repetitive
Immutable updates were hard and easy to get wrong
Common patterns (thunks, immutable updates, devtools) required many
separate libraries and configs

Redux Toolkit solves these by bundling the best Redux practices into one package with a simple API.
RTK is built around three ideas:

Simplicity: Write less code.
Predictability: Opinionated patterns to avoid mistakes.
Power: Includes tools for async logic, immutable updates, and store
setup.

Why Redux Toolkit Exists

Before RTK, a typical Redux app required:

action types
action creators
reducers with switch statements
manual immutable updates
configuring applyMiddleware
installing thunk, devtools enhancer, combineReducers, etc.

This made Redux feel complicated for beginners.
Redux Toolkit reduces all that to:

createSlice
configureStore
createAsyncThunk
createReducer and createAction (lower-level APIs)

With RTK:

reducers are auto-generated from slices
immutable updates are done automatically using Immer
store setup is one line
async logic is simpler
no need for switch statements or constants

In this article, we will learn a lot about Redux Toolkit by building a shopping cart. And to gain the most from this article, I have listed the prerequisites below in the next section.

Prerequisites

NodeJS should be installed on your system
Knowledge of React
Knowledge of JavaScript
Knowledge of Redux is not required, but it is an added advantage

Getting Started

To get started, clone the starter project by running the code below:

git clone https://github.com/lawrence-eagles/shopping-cart-starter shopping-cart

Then change directory by running:

cd shopping-cart

Now start the app by running:

npm run dev

And we get:

Building A Shopping Cart

In this section, we will focus on building a shopping cart. And to do this, we first need to set up our store.

Configure the Store

Redux store and Redux are kind of used interchangeably; both stand for a container for JavaScript apps. And this stores the whole state of the app in an immutable object tree.

To configure the Redux store, create an app directory inside the src directory. Then create a file named store.js inside the src directory. Now add the code below to the store.js file:

// app/store.js

import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "../features/counter/counterSlice";

export const store = configureStore({
  reducer: { },
});

After configuring the store, we need to provide the global state to our application.

Provide the Store to React

To provide the store to React, replace the code in the main.jsx with the following code:

import React from 'react';
import { createRoot } from 'react-dom/client';
import { store } from './store';
import { Provider } from 'react-redux';

import './index.css';
import App from './App';

const container = document.getElementById('root');
const root = createRoot(container);

root.render(
 <React.StrictMode>
   <Provider store={store}>
     <App />
   </Provider>
 </React.StrictMode>
);

In the code above, we used the Provider component to provide our store — our global state, to our application. Next, we create a slice.

Create a Slice

A slice in Redux Toolkit is a collection of Redux logic for a single feature of your application. It bundles state, reducers, and action creators into one cohesive unit.
Think of a slice as one feature = one slice.
In this section, we will create the cart slice and the modal slice for the cart feature and the modal feature. To do this, create a folder called features in the src directory and create a folder named cart inside the features directory. Next, create a file named cartSlice.js in the cart folder and add the following code to the cartSlice.js file:

import { createSlice } from "@reduxjs/toolkit";
import cartItems from "../../cartItems";

const initialState = {
 cartItems,
 amount: 0,
 total: 0,
 isLoading: false,
};

const cartSlice = createSlice({
 name: "cart",
 initialState,
 reducers: {
   clearCart: (state) => {
     state.cartItems = [];
   },
   removeItem: (state, action) => {
     const itemId = action.payload;
     state.cartItems = state.cartItems?.filter((item) => item.id !== itemId);
   },
   increase: (state, { payload }) => {
     const cartItem = state.cartItems.find((item) => item.id === payload);
     cartItem.amount += 1;
   },
   decrease: (state, { payload }) => {
     const cartItem = state.cartItems.find((item) => item.id === payload);
     cartItem.amount -= 1;
   },
   calculateTotals: (state) => {
     let amount = 0;
     let total = 0;

     state.cartItems.forEach((item) => {
       amount += item.amount;
       total += item.amount * item.price;
     });

     state.amount = amount;
     state.total = total;
   },
 },
});

// console.log("cartSlice", cartSlice)

export const { clearCart, removeItem, increase, decrease, calculateTotals } =
 cartSlice.actions;

export default cartSlice.reducer;

In the code above, the initialState has four properties: the cartItems, which is the cartItems data, amount, which is 0, total, which is 0, and isLoading, which is false.

In the createSlice, we created five reducers to handle different actions. These reducers are clearCart, removeItem, increase, decrease, and calculateTotals. Then we exported five action creators, which are automatically created with the same name as the reducers provided. Redux Toolkit automatically creates these action creators for us.

Also, RTK uses Immer.js internally, allowing you to write “mutating” logic safely as seen in the reducers in the code above.
Finally, Redux Toolkit automatically generates a slice reducer, which is exported using the default export.
Next, in the features directory, create a folder called modal and inside the modal folder create a file called modalSlice.js and add the code below to the modalSlice.js file:

import { createSlice } from "@reduxjs/toolkit";

const initialState  = {
   isOpen: false,
}

const modalSlice = createSlice({
   name: 'modal',
   initialState,
   reducers: {
       openModal: (state, action) => {
           state.isOpen = true;
       },
       closeModal: (state, action) => {
           state.isOpen = false;
       }
   }
})

export const {openModal, closeModal} = modalSlice.actions;
export default modalSlice.reducer;

In the code above, the initialState has only the isOpen property, which is false. And in the createSlice function, we created two reducers: openModal and closeModal. Additionally, two action creators with the same names as these reducers are automatically created for us by Redux Toolkit, and they are exported.
Finally, a slice reducer is automatically created by Redux Toolkit, and this is exported using the default export.
Next, we need to add both slice reducers to the application store, and we will do this in the next section.

Update Store

To add the slice reducers to the application store, update the code in the store.js file with the following:

import { configureStore } from "@reduxjs/toolkit";
import cartReducer from "./features/cart/cartSlice";
import modalReducer from "./features/modal/modalSlice";

export const store = configureStore({
   reducer: {
       cart: cartReducer,
       modal: modalReducer,
   },
})

Now both the cartReducer and the modalReducer are available to the entire app through the provider.

Use the Store in Components

To do this, add the following code to the App.jsx file:

import { useEffect } from "react";
import Navbar from "./components/Navbar";
import Modal from "./components/Modal";
import CartContainer from "./components/CartContainer";
import { useDispatch, useSelector } from "react-redux";
import { calculateTotals } from "./features/cart/cartSlice";

function App() {
 const { cartItems, isLoading } = useSelector((store) => store.cart);
 const { isOpen } = useSelector((store) => store.modal);
 const dispatch = useDispatch();

 useEffect(() => {
   dispatch(calculateTotals());
 }, [cartItems]);

 return (
   <>
     {isLoading && (
       <div className="loading">
         <h1>Loading...</h1>
       </div>
     )}
     <main>
       {isOpen && !isLoading && <Modal />}

       {!isLoading && (
         <>
           <Navbar />
           <CartContainer />
         </>
       )}
     </main>
   </>
 );
}
export default App;

In the code above, cartItems, isLoading, and isOpen are destructured from the store using the useSelector hook provided by react-redux.
Also, react-redux provides the useDispatch hook, which returns the store’s dispatch function. Additionally, calling dispatch(calculateTotals()) sends the action to the Redux store, and the slice reducer handles it and updates the state.

Next, we will create the Modal, the Navbar, and the CartContainer components.
To do this, in the src directory, create a folder named components and in the components folder, create a file named Modal.jsx and add the following code to the Modal.jsx file:

import React from 'react'
import { useDispatch } from 'react-redux'
import { clearCart } from '../features/cart/cartSlice'
import { closeModal } from '../features/modal/modalSlice'

const Modal = () => {
 const dispatch = useDispatch()
 return (
   <aside className="modal-container">
       <div className="modal">
           <h4>remove all items from your shopping cart?</h4>
           <div className="btn-container">
               <button type="button" className='btn confirm-btn'
               onClick={()=> {
                 dispatch(clearCart())
                 dispatch(closeModal())
               }}>confirm</button>

               <button type="button" className='btn clear-btn'
               onClick={()=> dispatch(closeModal()) }>cancel</button>
           </div>
       </div>
   </aside>
 )
}

export default Modal

Next, create a file named Navbar.jsx inside the components folder that is in the src directory. And add the following code to the Navbar.jsx file:

import {CartIcon} from "../icons";
import { useSelector } from "react-redux";

const Navbar = () => {
   const {amount} = useSelector((store)=>store.cart)
   
   return(
       <nav className='nav-center'>
           <h3>redux toolkit</h3>
           <div className="nav-container">
               <CartIcon />
               <div className="amount-container">
                   <p className="total-amount">{amount}</p>
               </div>
           </div>
       </nav>
   )
}

export default Navbar;

Lastly, create a file named CartContainer in the components directory and add the following code to the CartContainer file:

import React from 'react'
import CartItem from './CartItem'
import { useSelector, useDispatch } from 'react-redux'
import { openModal } from '../features/modal/modalSlice'

const CartContainer = () => {
 const dispatch = useDispatch();
 const {cartItems, total, amount} = useSelector((store)=>store.cart)

 return (
   <>
     {amount < 1 && (
       <section className="cart">
         <header>
           <h2>
             your bag
           </h2>
           <h4 className="empty-cart">is currently empty</h4>
         </header>
       </section>
     ) }

     {amount && (
       <section className="cart">
         <header>
           <h2>your bag</h2>
         </header>
         <div>
           {cartItems.map((item)=> (
             <CartItem key={item.id} {...item} />
           ))}
         </div>
         <footer>
           <hr />
           <div className="cart-total">
             <h4>
               total <span>${total.toFixed(2)}</span>
             </h4>
           </div>
           <button className="btn clear-btn"
             onClick={()=>dispatch(openModal())}>clear cart</button>
         </footer>
       </section>
     )}
   </>
 )
}

export default CartContainer

In the code above, we see that we map through the cartItems and pass each item to the CartItem component. So we need to create the CartItem component. And to do this, create a file called CartItem.jsx in the components directory and add the following code to the CartItem.jsx file:

import React from 'react'
import { ChevronDown, ChevronUp  } from '../icons'
import { useDispatch } from 'react-redux'
import { removeItem, increase, decrease } from '../features/cart/cartSlice'

const CartItem = ({id, img, title, price, amount}) => {
 const dispatch = useDispatch()
 return (
   <article className="cart-item">
     <img src={img} alt={title} />
     <div>
       <h4>{title}</h4>
       <h4 className="item-price">${price}</h4>
       <button className="remove-btn"
         onClick={()=> dispatch(removeItem(id))}>remove</button>
     </div>
     <div>
       <button className="amount-btn"
         onClick={()=> dispatch(increase(id))}>
         <ChevronUp />
       </button>
       <p className="amount">{amount}</p>
       <button className="amount-btn"
       onClick={()=> {
         if(amount === 1) {
           dispatch(removeItem(id))
           return;
         }
         dispatch(decrease(id))}}>
         <ChevronDown />
       </button>
     </div>
   </article>
 )
}

export default CartItem

Now, when you view the application, you get:

Conclusion

Redux Toolkit has completely transformed how developers use Redux.
What was once seen as too complicated is now simple, elegant, and enjoyable.
The above application is a simple application that shows how Redux Toolkit is set up and the overall structure of an application. However, I do hope that by following this application, you will get an understanding of Redux Toolkit and how it is used with React.
If you’re still managing state with plain Redux, now is the time to switch. You’ll write cleaner code, reduce bugs, and enjoy a better development experience.

The Complete Guide to Angular Subscriptions: Template vs. Component Logic

Wed, 19 Nov 2025 18:25:11 +0000

Every Angular developer eventually faces the dilemma: How do I get my data out of the Observable?

There are two correct answers, and they serve different purposes. Let's look at the code for both.

Scenario 1: Pure Display (The Happy Path)

If your data is just going onto the screen, use the Async Pipe. It is Declarative, meaning you describe what you want (the stream value), not how to get it.

The Code:

// component.ts
data$ = this.service.getData(); // No subscription here!

<p>{{ data$ | async }}</p>

Verdict: Use this 90% of the time. It prevents memory leaks automatically.

Scenario 2: Component Logic (The Necessary Evil)

Sometimes, the Async Pipe isn't enough. You might need to:

Filter data based on local state.
Trigger a side effect (like a Toast notification).
Patch a Form Control value.

Here, you must subscribe. And to avoid Zombie Components (listeners that stay alive after the component dies), you need the takeUntil pattern.

The Code:

export class MyComponent implements OnDestroy {
  private destroy$ = new Subject<void>();

  ngOnInit(): void {
    this.dataService.getData()
      .pipe(takeUntil(this.destroy$)) // Use takeUntil with the destroy$ subject
      .subscribe(response => {
        this.data = response;
        this.form.patchValue(response); // Specific logic!
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next(); // Emit a value to signal completion
    this.destroy$.complete(); // Complete the subject
  }
}

Key Takeaway:
Don't be afraid of manual subscriptions, but respect them. They require explicit cleanup logic. If you can avoid them by using | async, do it. If not, use takeUntil.

Stop Fetching Data in useEffect: Redux Edition

Wed, 30 Jul 2025 07:23:38 +0000

In Part 1, we talked about why fetching data directly inside useEffect is a flawed approach — tightly coupling component lifecycle to data-fetching logic, leading to unmanageable side effects, broken UX, and stale state bugs. We compared it to jQuery’s imperative data flows and showed how React in 2025 demands a more declarative mental model.

But the story doesn’t end there.

In this second part, we tackle an even more common anti-pattern, especially in Redux-heavy codebases:
Dispatching async thunks from useEffect.

useEffect(() => {
  dispatch(fetchUserData(userId))
}, [userId])

It might look cleaner than raw fetch(), but it inherits the same rot underneath.

Why This Pattern Still Exists

Before React Hooks, data fetching in Redux apps happened in componentDidMount(), with connected components via connect() HOCs. That lifecycle-to-dispatch model was normative.

When hooks arrived with useEffect, developers naturally ported this over. This became the de facto pattern. Even the official React-Redux docs show this for simple use cases.

It was a one-to-one migration. And at the time, it made sense.

You needed to kick off a thunk or saga somewhere, and useEffect was the hammer for all side-effect nails.

But Redux evolved.

As Mark Erikson (Redux maintainer) has repeatedly emphasized:

"You probably don’t need useEffect. And if you're dispatching from it, it's likely a code smell."

Yet, many codebases (even recent ones) still cling to the old dispatch-in-useEffect dance. Let’s unpack why that’s a problem.

The Core Problem

This pattern:

Delays data availability until after first render
Forces you to manage loading and error state manually
Ties async logic to the lifecycle, not the state graph
Doesn’t support SSR or Suspense
Is verbose, hard to test, and easy to misuse
Encourages repetition (every page/component reimplements fetch logic)

Worse, this makes your components non-composable. You can’t reuse this logic in another component without copy-pasting or lifting.

You're not modeling data — you're modeling timing.

But Isn’t Redux Still Useful?

It is — but not for remote server data.

Redux is great for:

Global, non-remote state (auth, UI toggles, preferences)
Workflow state (multi-step forms, undo/redo, complex user flows)
Cross-cutting logic (feature flags, permission checks)

But for:

Fetching lists
User profiles
Paginated feeds
Notifications
Dashboard metrics

...classic Redux is too much ceremony.

You don’t need reducers, actions, thunks, and selectors just to load some damn data.

You need a query layer — not a state machine factory.

Is dispatch() in useEffect() Always Wrong?

Not strictly.

Sometimes you genuinely need to dispatch on mount, maybe to initialize a websocket, fire a metrics event, or pre-warm a cache.

But when you're fetching render-critical data, dispatching inside useEffect means you're reacting too late.

You’ve already rendered once.
You’ve already missed the chance to prefetch or SSR.
You’ve already broken the declarative contract.

If You Have to Use Classic Redux

Encapsulate the dispatch logic in a custom hook to decouple data orchestration from your component:

function useUserData(userId) {
  const dispatch = useDispatch()
  const data = useSelector(state => state.users[userId])
  const loading = useSelector(state => state.loading.users[userId])

  useEffect(() => {
    dispatch(fetchUserData(userId))
  }, [userId])

  return { data, loading }
}

Then use declaratively:

const { data, loading } = useUserData(userId)

This way:

Your component stays declarative
The effect logic is testable and reusable
You reduce boilerplate inside the view layer

Still far from ideal — but survivable.

So What Should You Do Instead?

Data fetching deserves better than a useEffect hack job. If your mental model is still stuck in 2019, it's time for a reset.

In Part 3, we’ll explore a declarative routing-first approach to data fetching using loader, useLoaderData, and compare that with popular solutions like RTK Query, TanStack Query, swr and even emerging Suspense APIs. We'll also address how to gracefully migrate away from this legacy pattern in large codebases.

And yes — there’s a way to do all this without ditching Redux if you don’t want to.

TL;DR

useEffect is not a data-fetching tool
Dispatching async thunks in useEffect is an outdated, fragile pattern
This made sense in pre-RTK Redux, but should be retired
Redux already solved this. It’s called RTK Query.
RTK Query, TanStack Query, and Loader APIs offer better abstractions
Declarative data > lifecycle-driven orchestration

If you’re still writing async thunks just to get a list of users, it’s time to ask yourself why.

You’re still not writing jQuery.
And now — you shouldn't be writing it with Redux either.

Nucleux

Tue, 24 Jun 2025 01:46:34 +0000

The Story Behind Nucleux

Nucleux emerged from a simple frustration: existing React state management solutions either require complex provider setups (like Context API) or cause unnecessary re-renders (like most global state libraries). After trying Redux, Zustand, Jotai, and building custom solutions, I realized developers needed something that combined atomic precision with organizational clarity.

How It Works

Nucleux uses atomic state management where each piece of state is independent. When you update an atom, only components subscribed to that specific atom re-render - no cascade effects, no provider hell.

class TodoStore extends Store {
  todos = this.atom([])
  filter = this.atom('all')
  
  addTodo(text) {
    this.todos.value = [...this.todos.value, { id: Date.now(), text }]
  }
}

function TodoApp() {
  const todoStore = useStore(TodoStore)
  const todos = useValue(todoStore.todos)
  
  return (
    <div>
      <button onClick={() => todoStore.addTodo('New task')}>
        Add Todo
      </button>
      <ul>
        {todos.map(todo => (
          <li key={todo.id}>{todo.text}</li>
        ))}
      </ul>
    </div>
  )
}

Key Features

Zero Providers: Use state anywhere without wrapping components
Atomic Updates: Only subscribed components re-render
Organized Architecture: Class-based stores group related state and methods
Built-in Persistence: Save to localStorage/AsyncStorage automatically
Dependency Injection: Stores can easily depend on other stores
Lightweight: Only 3.5KB gzipped
SSR Compatible: Works seamlessly with Next.js and server-side rendering

Three Powerful Hooks

useStore(StoreClass) - Access store methods

const todoStore = useStore(TodoStore)
todoStore.addTodo('New task')

useValue(atom | StoreClass, 'atomKey') - Subscribe to specific atoms

const todos = useValue(todoStore.todos)
// or
const todos = useValue(TodoStore, 'todos')

useNucleux(StoreClass) - Get everything at once

const { todos, filter, addTodo } = useNucleux(TodoStore)

Get Involved

Try it: npm install nucleux or check the live demo
Contribute: Visit GitHub for issues and feature requests
Documentation: Full guides at nucleux.dev

We're looking for contributors who understand React performance, state management patterns, and developer experience. Whether it's bug fixes, new features, or documentation improvements - all contributions are welcome!

State Management Made Easy with Fluxor in Blazor

Fri, 25 Apr 2025 12:59:35 +0000

Exploring Actions, Effects, and the Benefits of Fluxor

Modern web applications are becoming increasingly complex, and with complexity comes the need for structured state management. In the world of Blazor a popular .NET-based web UI framework .

Fluxor offers a powerful yet easy-to-understand state container that brings predictable state flow to your applications.

Fluxor is a zero-boilerplate Flux/Redux library for Microsoft .NET.

It brings the same clean architecture and unidirectional data flow popularized by Redux in the JavaScript ecosystem—adapted for C# developers building with Blazor.

We’ll break down the core concepts of Fluxor and show how you can use Actions, Reducers, and Effects to create a clean, maintainable architecture.

Explore the GitHub project

️ What is Fluxor?

Fluxor provides a structured and predictable way to manage state in your Blazor application. Inspired by Redux, it embraces:

Unidirectional data flow — State changes follow a clear path: Action ➝ Reducer ➝ State ➝ UI.

Single source of truth — All application state lives in a centralized, immutable store.

Middleware & Effects — Separate side-effects like API calls from your UI and business logic.

Unlike some Redux implementations, Fluxor handles a lot of the boilerplate for you with C#-friendly conventions and strong typing.

Actions – Declaring Intent

In both Redux and Fluxor, Actions are plain messages that describe what happened. They're just
signals , they don’t contain logic.

Example:

public record FetchItemsAction;
public record FetchItemsSuccessAction(List<Item> Items);
public record FetchItemsFailedAction(string ErrorMessage);

⚙️ Effects – Handling Side Effects

Since Reducers must be pure, Effects in Fluxor allow you to perform async operations like API calls without cluttering your UI.

Example:

public class ItemEffects
{
    [EffectMethod]
    public async Task HandleFetchItems(FetchItemsAction action, IDispatcher dispatcher)
    {
        try
        {
            var items = await itemService.GetItemsAsync();
            dispatcher.Dispatch(new FetchItemsSuccessAction(items));
        }
        catch (Exception ex)
        {
            dispatcher.Dispatch(new FetchItemsFailedAction(ex.Message));
        }
    }
}

This Effect reacts to FetchItemsAction and handles fetching data from an external service.

State and Reducers – Updating the Store

Reducers are responsible for updating state in response to actions. They are pure functions and return a new state based on the action received.

public static class ItemReducers
{
    [ReducerMethod]
    public static ItemState OnFetchSuccess(ItemState state, FetchItemsSuccessAction action) =>
        state with { Items = action.Items, IsLoading = false };

    [ReducerMethod]
    public static ItemState OnFetchFailed(ItemState state, FetchItemsFailedAction action) =>
        state with { ErrorMessage = action.ErrorMessage, IsLoading = false };
}

Reducers never mutate state—they return a new state object.

Try It Yourself

Check out the working example project to see all these concepts in action:
https://github.com/stevsharp/BlazorAndFluxorStateMachine

It demonstrates:

Dispatching Actions from UI
Handling async logic with Effects
Clean Reducer logic
Blazor component integration

✅ Why Use Fluxor?

No boilerplate overload – clean C# syntax
Clear, testable state transitions
Great for scaling large Blazor apps
Familiar to those who’ve used Redux in React or Angular
Keeps business logic and UI concerns separate

References

Fluxor GitHub Repository

Redux Official Site

Angular Redux

Blazor Documentation – Microsoft

BlazorAndFluxorStateMachine – GitHub Sample

List item

The Role of State Management in Building Scalable Front-End Applications

Mon, 25 Nov 2024 01:11:12 +0000

Importance of state management concepts in Front-End

Today’s front-end applications are more complex and powerful than ever before. The days when the logic was handled solely on the back-end, with the front-end serving as a simple data display layer, are long gone. Modern applications are expected to deliver dynamic, interactive, and seamless user experiences, often requiring sophisticated data management. One essential tool for handling this complexity is state management.

State management allows developers to build scalable and maintainable applications by organizing and controlling data flows. For developers working with popular frameworks, there are ready-to-use solutions like Redux for React and NgRx for Angular. However, this article will focus on the general principles and concepts of state management, which apply to any tool or framework.

What is State Management: Delving into the theory

In simple terms, “state“ refers to the data at a particular moment in time — such as user information, UI state, or data retrieved from APIs. This data can either be local (specific to a component or group of components) or global (accessible throughout the entire application).

Local state is used within a particular component to manage its data independently. For instance, imagine a form where fields depend on values from other fields. To handle these dynamic relationships, the local state can be applied to simplify data management within that form. Conversely, the global state enables data sharing across the entire application. Take user settings, for example — preferences like theme settings or language choices that should be accessible from any page. Global state provides centralized access to this data, ensuring consistency across the app.

Without properly managing this data you are likely to get “spaghetti code“. Additionally, it will help you to reduce code duplication and enhance component communication.

Pillars of State Management: Core Concepts

Regardless of the tool or framework, some essential principles are critical to implementing effective state management.

Firstly, there’s the Single Source of Truth principle, which states that all data should be stored and updated in a single location. This approach simplifies data tracking and updates by ensuring there’s only one source for each piece of data, providing consistent access across the application. With centralized data handling, debugging becomes easier, especially in complex applications.

Another vital principle is Unidirectional Data Flow. This concept mandates that data flows in a predictable manner from a single source and is modified in a controlled way. This greatly reduces the potential for bugs, and provides a predictable structure, making the application’s behavior easier to understand and troubleshoot.

Finally, there’s the principle of Separation of Concerns, which recommends separating business logic from UI concerns. By doing so, state management keeps business logic — such as data handling and updates independent from the UI. Components can focus solely on displaying data, while complex state logic is handled separately. This modular approach leads to a codebase that’s easier to maintain and update.

These principles provide a foundation for any state management solution. Whether you choose an existing library or decide to build a custom solution, following these core ideas will help keep your application organized and scalable.

The Challenges of Unmanaged State: What can it cost to you

One of the most common problems is data inconsistency. When the state isn’t centrally managed, data inconsistencies frequently arise. Imagine a scenario where you’re editing content on the same page where it’s displayed. After making changes and pressing “Update“ or “Save“, you expect the displayed data to refresh. However, if there’s no centralized state, you might see outdated content until you refresh the entire page, creating confusion for a user.

Debugging also becomes difficult when the state is not centralized. Initially, tracing bugs and errors might seem manageable, but as the application grows, tracking the source of data and understanding where updates occur can quickly become a complex and time-consuming task.

Lastly, code duplication becomes almost unavoidable without centralized state management. When components independently manage related data, duplications are likely to arise. This can quickly bloat the codebase, making it harder to maintain and increasing the chances of introducing bugs.

When to Use State Management: Tips for Implementation

Not every application requires state management, so it’s crucial to evaluate your project’s needs. For simpler applications, such as a single landing page, state management might add unnecessary complexity. However, as soon as your application has shared data across multiple components or requires complex user interactions, state management becomes beneficial.

If your application has complex user flows — where data needs to be shared across different components or pages — then state management can help you improve maintainability. For simpler projects, though, it can be overkill.

If you determine that state management is necessary, start with a simple approach. Begin by managing the state locally within individual components and only scale up to a more comprehensive state management solution as the complexity of your application grows. Avoid overengineering early on; it’s best to let your solution evolve naturally alongside your app’s needs.

As you expand your state management, keep it as organized as possible. Avoid creating one large state object, as this can quickly become difficult to maintain. Instead, break your state into smaller, manageable sections that can be updated independently, helping keep your state clean and manageable.

Another valuable tip is to separate your business logic from the UI. Place business logic within your state management layer rather than in UI components. This makes your components easier to reuse, as they focus solely on displaying data rather than managing it. This separation also results in modular, testable code that’s easier to debug and extend.

Conclusion: Know your tools and needs

If your project is expanding, now is the time to evaluate whether your current approach to state management meets your needs. Start small and simple, but don’t hesitate to adopt a more structured solution as your app grows. Explore tools and practices that align with your project’s requirements, and experiment with different techniques to find what works best. The right state management approach will make your application more robust, scalable, and easier to maintain in the long run. Start integrating these principles today and see the positive impact on your development process and overall code quality!

Useful Links:
https://redux.js.org/
https://ngrx.io/guide/store/why