Proposal: Move orchestration to a middleware

[smikula]

The primary purpose of Satchel is as a state management library: actions are dispatched and handled by mutators in order to modify the store. Once we have this publish-subscribe pattern established, it's convenient to be able to reuse it for side effects and orchestrating between disparate components, hence the orchestrator API. But it's perfectly reasonable to use Satchel without orchestrators (in many cases a simple function can accomplish the same thing).

Also, as they exist today, there is no ordering guarantee among subscribers to an action. There are cases where it would be convenient for an orchestrator to deterministically execute before or after a given action has been handled; for example, if you specifically want to do perform side effect given the new state of the store. A middleware provides the opportunity to do this.

I propose the following;

• Deprecate the orchestrator API.

• Create a new package, e.g. satcheljs-orchestration which exports the orchestrator middleware. (Or the middleware could live in satcheljs, but the point is that this is separate functionality that consumers can choose to opt into.)

• Instead of orchestrator, expose two ways to subscribe: before and after. Usage:

  import { before, after } from 'satcheljs-orchestration';
  import { someAction } from './actions';
  
  before(someAction, actionMessage => {
      // Do something before someAction has mutated the store
  });
  
  after(someAction, actionMessage => {
      // Do something after someAction has mutated the store
  });
  

[ericrallen]

I like the direction this is headed.

The old dispatch Action -> Orchestrator -> dispatch another Action -> Mutator pattern works fine, but this feels more intentional and explicit.

I'm assuming in this case any value returned from the before becomes the new actionMessage that is passed to the Mutator?

[Adjective-Object]

+1 to the explicit before and after in this proposal. I've seen instances where ambiguous execution order of orchestrators vs mutators leads to subtle bugs and hard to maintain code when orchestrators take data dependencies on the store.