Exposing a subset of the Store API to middleware

[ekweible]

This is primarily a question about a difference between the middleware API here versus the JS version.

redux.js exposes only a subset of the Store's API (getState() and dispatch()) to middleware, whereas redux.dart provides the entire Store instance. Are there any valid use cases where having access to reducer, onChange, or teardown justifies their presence?

It seems to me that using those additional Store APIs in middleware would usually be considered anti-patterns and limiting middleware to just the Store's state and dispatcher would be a useful constraint and would make test setups a bit simpler (although this might be a marginal improvement, at best).

Obviously this would be a breaking API change, and the benefit of preventing misuse in middleware and aligning with redux.js is relatively small, so I definitely understand if you decide the juice isn't worth the squeeze. Maybe something to consider in the future if you have other reasons for a new major version.

[johnpryan]

This is a good suggestion, thanks Evan :) Yeah, it's a breaking change, but it looks to me like people aren't using reducer onChange or teardown in middleware right now anyway:

https://github.com/brianegan/redux_logging/blob/master/lib/redux_logging.dart#L121
https://github.com/Cretezy/redux_persist/blob/master/packages/redux_persist/lib/redux_persist.dart#L208
https://github.com/brianegan/dart_redux_epics/blob/master/lib/src/epic_middleware.dart#L40

This was just my quick collection of some middleware I see on Pub.

[jnorkus]

I have just come across this. I am missing the onChange in the epic middleware, so I forked the repo to add that. How would you go about accessing the state stream without that? In my epics I usually want to watch the state to wait for some condition before continuing.