injectable middlewares, with typed hook

[EskiMojo14]

playing around with some ideas based on redux-dynamic-middlewares and createListenerMiddleware

typically the issue with injectable middlewares is that the dispatch typing is unaware of them, so i thought a custom useDispatch-style hook returning a dispatch that's aware of the middlewares it's injected could be useful

codesandbox here

so far i've just reused redux-dynamic-middlewares' logic for managing injected middleware - there's nothing to prevent the same middleware being injected twice, etc. i did however change it so that you dispatch an action to add middleware, instead of exporting methods on an instance (as i wasn't entirely keen on the fact that createDynamicMiddlewares assumes you'll use the instance with only one store)

edit:

i've now adapted it to use the same logic createListenerMiddleware uses to manage its listeners - each middleware entry has a map of MiddlewareAPI to the applied version of that middleware, to avoid doing it every dispatch

[EskiMojo14]

I've now changed the API and management logic to much more closely resemble createListenerMiddleware:

export const dynamicInstance = createDynamicMiddleware();

export const startAppMiddleware = dynamicInstance.startMiddleware as TypedStartMiddleware<
  RootState,
  AppDispatch
>;

export const stopAppMiddleware = dynamicInstance.stopMiddleware as TypedStopMiddleware<
  RootState,
  AppDispatch
>;

export const addAppMiddleware = addMiddleware as TypedAddMiddleware<
  RootState,
  AppDispatch
>;

export const removeAppMiddleware = removeMiddleware as TypedRemoveMiddleware<
  RootState,
  AppDispatch
>;

export default dynamicInstance.middleware;

the main challenge is to try and get a version of dispatch that knows about any injected middlewares, which is why i thought it could be useful if dispatching addMiddleware returned a pre-typed dispatch wrapper (with an attached method to remove the injected middleware)

const mwAwareDispatch = dispatch(addMiddleware(middleware1, middleware2));
mwAwareDispatch(action(payload));
mwAwareDispatch.remove();

the hook would still be preferable in the context of a component of course, but that's not always available (and i'm not 100% sold on the logic inside that hook yet)

const dispatch = useMiddlewareDispatch(middleware1, middleware2);

using the map entry style from createListenerMiddleware, it's no longer a concern if the same middleware is injected twice - if it's the same function reference it'll use the same entry.

[EskiMojo14]

one issue with the "one entry per middleware" approach of course, is that it would remove the middleware if any of the users removed it - this may end up opening a can of worms with managing subscribers and only removing the middleware if there are no subscribers left

[phryneas]

Some ideas.

• we already have createAsyncThunk.withTypes, so maybe we can use that pattern more?

export const addAppMiddleware = addMiddleware.withTypes<RootState, AppDispatch>();
// or, for consistency:
export const addAppMiddleware = addMiddleware.withTypes<{ state: RootState, dispatch: AppDispatch}>();

• I don't see the point in removing middleware. The main point in dynamically adding it is bundle splitting - and in that light removing middleware doesn't seem to give any benefits. But as you note, it opens another can of worms. So maybe we stay out of that? Middleware can still always decide if they do something or not.
• I would opt for splitting the hook:

// in another file 
export const useDispatchWithExtraMw = dispatchHookWithMiddleware(middleware1, middleware2)
//in the component 
const dispatch = useDispatchWithExtraMw ();

That would keep the middleware itself out of the component file, and we could already inject when useDispatchWithExtraMw is called - which would be outside the render cycle, when the bundle with the middleware is loaded for the first time.

[phryneas]

I'm not sure how this would be achieved, could you give an example? I could definitely make it so that you can create a hook like that instead of importing the middleware into the component, but I'm unsure how to achieve the middleware being injected without either having access to dispatch already or access to the dynamicMiddleware instance

I would have assumed dispatchHookWithMiddleware to be a propterty of dynamicInstance.
Generally, I'm not sure if we need a dispatchable version of addMiddleware - do you think we could get around that, by having it attached to the instance in all cases instead? Or are there use cases where we wouldn't get around that?

[EskiMojo14]

I would have assumed dispatchHookWithMiddleware to be a propterty of dynamicInstance.

gotcha, makes sense

Generally, I'm not sure if we need a dispatchable version of addMiddleware - do you think we could get around that, by having it attached to the instance in all cases instead? Or are there use cases where we wouldn't get around that?

the main reason i wanted addMiddleware to be dispatchable is that we could then return a pre-typed version of dispatch from it, which i don't think would be possible for the method attached to the dynamicInstance

[phryneas]

Hmm yeah, I could see that possible use case.

[EskiMojo14]

in terms of naming, maybe the attached instance method could be addMiddleware, and the action could be withMiddleware i.e. const mwDispatch = dispatch(withMiddleware(mw2, mw2))

[phryneas]

Sounds good to me.

[EskiMojo14]

I've opened #3256 for a proper place to store the lib code, and updated the CSB to include some actual (if contrived) example of lazy loading components/middleware. :)

[EskiMojo14]

I've also implemented the changes suggested by @phryneas

[EskiMojo14]

opened #3292 and closed #3256 as some complications with imports made it very likely this will need to be a 2.0 thing

[EskiMojo14]

wonder if it's worth scoping the withMiddleware action to the instance (with an ID or something) - it might be desireable to have multiple dynamicMiddleware instances (e.g. one before all static middlewares, and one after)