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
#128 introduced a new feature to be able to track the completion of reduction of actions and effects. This introduces certain overhead, so it is made optional per store using the lager::with_futures reducer.
Ideally, however, this could be made optional per call to dispatch. There are two ways:
Add a different version of dispatch() (name suggestions? dispatch_future(), dispatch_(), dispatch_with(), ???) that returns a future, and have the default version not return one at all. In the current version, dispatch() always returns a future, but you get runtime errors when using the returned future if futures are not enabled in the store.
This is probably cleanest option from an API POV but, in a trivial implementation, it imposes some penalty to creating and passing around contexes. Maybe there is a way we can instead of carrying around the dispatchers for various actions as function objects in the context, we create a static vtable for a particular combination of actions and parent context. Implementing this optimization, while a bit difficult, would also be more efficient than what we currently have for the general case.
Add a flag to dispatch(a, [flag]) to enable futures for each dispatch call.
The text was updated successfully, but these errors were encountered:
#128 introduced a new feature to be able to track the completion of reduction of actions and effects. This introduces certain overhead, so it is made optional per store using the
lager::with_futures
reducer.Ideally, however, this could be made optional per call to dispatch. There are two ways:
Add a different version of
dispatch()
(name suggestions?dispatch_future()
,dispatch_()
,dispatch_with()
, ???) that returns a future, and have the default version not return one at all. In the current version,dispatch()
always returns a future, but you get runtime errors when using the returned future if futures are not enabled in the store.This is probably cleanest option from an API POV but, in a trivial implementation, it imposes some penalty to creating and passing around contexes. Maybe there is a way we can instead of carrying around the dispatchers for various actions as function objects in the
context
, we create a static vtable for a particular combination of actions and parent context. Implementing this optimization, while a bit difficult, would also be more efficient than what we currently have for the general case.Add a flag to
dispatch(a, [flag])
to enable futures for each dispatch call.The text was updated successfully, but these errors were encountered: