Open ekweible opened 6 years ago
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.
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.
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()
anddispatch()
) to middleware, whereas redux.dart provides the entireStore
instance. Are there any valid use cases where having access toreducer
,onChange
, orteardown
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.