Skip to content
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.

Providing effect payload and name to middleware #33

Open
aweary opened this issue May 5, 2017 · 1 comment
Open

Providing effect payload and name to middleware #33

aweary opened this issue May 5, 2017 · 1 comment

Comments

@aweary
Copy link

aweary commented May 5, 2017

Currently, middleware is just invoked with the entire state tree and effects list on every update. Middleware is especially useful when it can respond to a specific subset of effects, as well as know what that effect contained.

The existing recommendation is to just overwrite the effects with a wrapping utility, but that doesn't seem consistent with what a middleware API should provide since that means you'd be redefining your effects every time an effect is triggered, which I can't imagine is great for performance either. You want your middleware to get the data it needs by default as well.

Can middleware be invoked at a different point in the code path so it has access to effect names
and effect payload without having to redefine effects on every update?

@divmain
Copy link
Contributor

divmain commented May 27, 2017

More discussion on this going on in #36. Would love your thoughts on it @aweary.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants