You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
Currently, middleware is just invoked with the entire
state
tree andeffects
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?
The text was updated successfully, but these errors were encountered: