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
  });