-
Notifications
You must be signed in to change notification settings - Fork 219
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
Can middleware trigger reducer execution? #43
Comments
Hey hey -- the example you've posted will produce an infinite loop (b/c it will always keep dispatching a new action), but I think I get the overall Q. The This test works, for example. It verifies that the action forwarded by the test('next actions reach reducer first', () async {
final List<dynamic> actions = <dynamic>[];
void middleware(
Store<String> store,
dynamic action,
NextDispatcher next,
) {
next(action);
if (action == 'I') {
store.dispatch('F');
}
}
String reducer(String state, dynamic action) {
actions.add(action);
return state;
}
final store = new Store<String>(
reducer,
middleware: [middleware],
);
store.dispatch('I');
expect(actions, ['I', 'F']);
}); |
Thanks Brian. I figured out what confused me yesterday when looking at this. Check this out: test('next actions reach reducer first', () async {
final List<dynamic> actions = <dynamic>[];
void middleware(
Store<String> store,
dynamic action,
NextDispatcher next,
) {
next(action);
if (action == 'Approve') {
store.dispatch('Save');
}
}
String reducer(String state, dynamic action) {
actions.add(action);
return state;
}
final store = new Store<String>(
reducer,
middleware: [
new LoggingMiddleware.printer(),
middleware],
);
store.dispatch('Approve');
expect(actions, ['Approve', 'Save']);
}); Even though this test passes (proving that reducers are running when expected), the logging middleware (which is all that I was using to analyze the situation yesterday) outputs:
This is the opposite of what I would intuitively expect, and I don't quite have my head around why this is. I note that swapping the order of my middleware helps: middleware: [
middleware,
new LoggingMiddleware.printer(),
], Gives me:
Should my logging middleware always be at the end of my middleware pipeline? Conceptually, when I think of dispatching an action, I imagine it traveling through the middleware in the order of definition (so putting the logging middleware first made sense to me, since I figured it would be the first thing to run on each action received). Am I misguided here? |
Heya Kent, Sorry, traveling the past few days! So, it looks like you found a bug in the Logger implementation :) I'll push up a fix next week when I'm back in action :) Best, |
Heya @kentcb -- I tried to fix this bug, but it caused other issues. The only way to get it to work consistently is to put the logger as the last middleware in the chain, which I found is the same restriction as the logging middleware for Redux.js as well. The problem? The middleware must call I've updated the documentation to reflect this! Sorry about the confusion. |
I just tried this, expecting it to work:
My expectation was that the
Approve
reducer would execute, and then theSave
action would be instigated. In reality, the opposite is true.Have I fundamentally misunderstood the middleware/reducer relationship here? Shouldn't forward an action onto the next piece of middleware eventuate in the action reaching the reducers before middleware continues execution?
The text was updated successfully, but these errors were encountered: