From Meta-Reducers to Store-Level Reducers

[oleksii-shepel]

Meta-reducers have been around for a long time.

They're powerful, flexible, and occasionally mysterious.

At some point, many developers discover that half of their application's behavior is no longer inside reducers at all—it's hiding in wrappers around reducers, wrappers around wrappers, or somewhere deep in a middleware chain that everyone is slightly afraid to touch.

You know the feeling:

"The state changed."

Great.

"Why did it change?"

Excellent question.

"Which meta-reducer did it?"

Let's schedule a meeting.

😄

This got us thinking about a different approach: Store-Level Reducers.

Instead of wrapping reducers from the outside, what if application-wide concerns participated directly in the state transition process?

Things like:

• persistence
• hydration
• analytics
• logging
• migrations
• state validation
• feature flags

Instead of being special infrastructure, they become first-class participants in the store itself.

Conceptually:

store.addReducer(loggingReducer);
store.addReducer(persistenceReducer);
store.addReducer(featureFlagsReducer);

Every reducer can see the action.

Every reducer can contribute to the next state.

No hidden wrapper chains.

No reducer inception.

No wondering whether you're debugging a reducer, a meta-reducer, or a meta-meta-reducer.

The idea is not necessarily to replace meta-reducers completely.

The question is whether application-wide behavior becomes easier to understand when it is represented as ordinary store-level logic rather than special infrastructure.

What do you think?

• Are meta-reducers still the right abstraction?
• Have they become too magical?
• Would store-level reducers be easier to reason about?
• How do you handle cross-cutting concerns in your applications today?