Redux Listener Middleware and React‑Toastify: Deciding Alert Logic Placement

Redux Listener Middleware and React‑Toastify: Deciding Alert Logic Placement

The goal is to choose a location for alert‑generating logic that keeps UI concerns decoupled from state updates while preserving testability and avoiding excessive re‑renders.

Constraints include ensuring that throttling/deduplication middleware runs after async thunks but before loggers, preventing notification state stored in the store from causing unnecessary component updates, and keeping the slice free of UI‑specific code.

Uncertainty remains whether to implement alert triggering as extra reducers within the notifications slice or to delegate it to a dedicated listener/middleware that dispatches a notification action.

Should alert‑triggering actions be handled by extra reducers in the notifications slice, or by a dedicated listener middleware? How does each approach affect unit test isolation and UI coupling? What impact does each have on middleware order and potential re‑render overhead?