-
-
Notifications
You must be signed in to change notification settings - Fork 15.2k
Simplify applyMiddleware #3570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify applyMiddleware #3570
Conversation
Deploy preview for redux-docs ready! Built with commit b3994bc |
Looks good and much easier to read through this way. Thanks, Jed! |
reducer: Reducer<S, A>, | ||
export default function applyMiddleware< | ||
S = any, | ||
M extends Middleware = Middleware |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this need to be generic? In what case would our middleware not be a Middleware
? Either we don't need this, or we need to add a test for this generic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's not generic, I can't infer off of it; rather, I do get errors if I try to do typeof middlewares extends Middleware<any, any, infer D>
.
Type '(createStore: StoreEnhancerStoreCreator<any, never>) => <S = any, A extends Action<any> = AnyAction>(reducer: Reducer<S, A>, ...args: any[]) => any' is not assignable to type 'StoreEnhancer<never, S>'.
Type '<S = any, A extends Action<any> = AnyAction>(reducer: Reducer<S, A>, ...args: any[]) => any' is not assignable to type 'StoreEnhancerStoreCreator<never, S>'.
Type 'any' is not assignable to type 'never'.ts(2322)
It will always be a Middleware
, which is why I said it must extend Middleware
, but there's no reason someone can't create an interface which extends Middleware
and use that too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we already have tests against this generic in the existing applyMiddleware.spec.ts
which pass just fine with npm run test:cov
for some reason; though, I am seeing red underlines in my editor (even before my changes here). I've fixed those red-line errors in other pieces of my work, but once I started breaking things apart, it's a bit harder to compose these things into smaller chunks w/o some overlap.
5b7dc47
to
5f716e8
Compare
5f716e8
to
b3994bc
Compare
Let me give a stab at some tests. |
Nope, this doesn't work the way I thought. The tests prove that. Side note, it doesn't work this way before my changes either. Should I submit a PR with breaking tests to show you what I mean? Or is my assumption incorrect? it('combines Dispatch types from all middlewares', () => {
const foo: Middleware<any, any, Dispatch<{ type: 'foo' }>> = ({
dispatch
}) => _next => _action => dispatch({ type: 'foo' })
const bar: Middleware<any, any, Dispatch<{ type: 'bar' }>> = ({
dispatch
}) => _next => _action => dispatch({ type: 'bar' })
const store = createStore(x => x, applyMiddleware(foo, bar))
store.dispatch({ type: 'foo' }) // OK
store.dispatch({ type: 'bar' }) // OK
store.dispatch({ type: 'baz' }) // not OK
}) The part TS doesn't like is |
Breaking up #3566 into smaller pieces.
This PR simplifies the types of
applyMiddleware
by replacing all the overloads with a single generic function signature that infers the union of any/allDispatch
types provided into a singleStoreEnhancer
. This implementation has the added benefit that you can provide as many middlewares as you want w/o maxing out at just 5.