comparison to (re)actors ??

I’m trying to decide whether my project should use sagas or (re)actors (or both), and besides the documentation for this project I have also read:

• http://jamesknelson.com/join-the-dark-side-of-the-flux-responding-to-actions-with-actors/
• https://medium.com/@mtiller/encapsulating-application-logic-with-reactors-392635763e7

Actors are a sequence of functions which are called each time your store’s state changes, with one important exception: they aren’t called in response to actions dispatched from other actors.

This isn’t really a property of actors, but of the suggested approach of hooking them up to the store:

// An array of actor functions taking a `state` object and `dispatch` function
var actors = [ ... ]

var acting = false
store.subscribe(function() {
  // Ensure that any action dispatched by actors do not result in a new
  // actor run, allowing actors to dispatch with impunity.
  if (!acting) {
    acting = true
    actors.forEach(function() {
      actor(store.getState(), store.dispatch)
    })
    acting = false
  }
})

They even go so far as to implement the connection between React and Redux as the final actor in the sequence, so that React render calls for intermediate synchronous states are avoided.

It seems as though both saga and actor approaches offer comparable side-effect management.

• is the actor approach better approach for synchronous side-effects in terms of React efficiency?
• is the saga approach better for asynchronous side-effects in terms of declaration and testing?
• is it likely that a project would ever benefit from using both? or do most use cases fit cleanly into either one or the other approach?

[yelouafi]

@slorber From the 1st link I think the author gives a different meaning to actors than the one commonly known in the Actor model.

@jokeyrhyme Actors in the Actor model communicates by sending messages to each other while in the above link the author talks about reacting to state changes. In the mentioned article, actors are functions invoked on each state change, can dispatch actions and forms a kind of a pipeline where each actor can see the results of actions dispatched by previous actors on the chain.

I can see 2 principal concerns from my rapid lecture

1. ability to dispatch actions in reactions to other actions
2. amelioration of performance rendering by not rendering on each state change

The 2nd concern seems more technical than conceptual and IMO can be handled by different means (like using redux-batched-actions).

The 1st concern joins somewhat the Saga purpose, as Sagas can also translate user events into business events that maybe handled by other Sagas. And those Sagas can in turn generate other events to be used by other Sagas.

I don’t see why the author chose to deliberately ignore actions and just examines state changes in order to infer the next action or effect. It means the developer will likely store more control state in the store in order to give re-actors enough information to decide what to do.

[jokeyrhyme]

Thanks everyone, that’s given me a lot to think about. 😃