Reputation: 2957
If I use createListenerMiddleware
to create 2 separate middlewares, that handle different responsibilities, is that going to have any significant performance cost over creating a single listener middleware? Are there any undesirable ways they can interact?
One concern is if I dispatch addListener
, removeListener
or clearAllListeners
, are they going to reach both middlewares, or be consumed by the first in the chain?
The alternative is creating a single shared listener middleware in its own module that can be imported to both the other modules to have listeners added, which would likely cover most use-cases but not if I want to pass in different extra arguments or different error handling.
Upvotes: 2
Views: 791
Reputation: 67489
I created the listener middleware :)
You should really only have one listener middleware instance in an app, and I can't really think of a good reason why you would want to have multiple listener middleware instances. And yes, the add/remove listener actions will definitely be handled and stopped by the first listener middleware instance that sees them, with no differentiation.
If the goal is to have separate listener+effect definitions that don't rely on importing the same middleware instance, I'd suggest trying the third file organization approach shown in the docs, where feature files export a callback that gets startListening
as a parameter:
// feature1Slice.ts
import type { AppStartListening } from '../../app/listenerMiddleware'
const feature1Slice = createSlice(/* */)
const { action1 } = feature1Slice.actions
export default feature1Slice.reducer
export const addFeature1Listeners = (startListening: AppStartListening) => {
startListening({
actionCreator: action1,
effect: () => {},
})
}
Upvotes: 4