Discussion on: Redux is half of a pattern (2/2)

[peerreynders]

other patterns (such as the Actor Model) exist for modeling distributed state and communication flow.

One possible danger I see is that people may once again focus on the wrong thing - Actors (XActor). Most of us are probably familiar with:

I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging".

Similarly the creators of Erlang never set out to implement Actors, they just happened to arrive in a similar place for pragmatic reasons:

I can’t remember if we knew about the actor model in 1985 I might have heard of it without knowing what it was. Erlang was directly influenced by smalltalk and prolog. The idea of messaging comes from smalltalk and CSP.

Even inspecting the concept demo code (for the Chrome Dev Summit 2018 video linked to) it becomes clear that it's the message store that is the driving force behind the idea - not the Actor (where the user code attaches).

So perhaps Redux got the message/event/action idea right but those messages should be directed towards isolated "machines" (behaviours) whose interface could be conceptually as simple as:

function receive(message, oldState) {
  // Based on finite state select how to
  // process the message and alter finite/extended state
  // 
  //...

  // Communicate with other machines
  // via messages (sent perhaps asynchronously).
  // ...
  send(toMachineN, messageOutM);

  // ... but rather than modifying state 
  // asynchronously (ala React hooks) 
  // issue a message to "self"
  // to alter state

  return newState; 
}

• message+state store: "I've got a message here for you so it's time to do some work - but be quick about it".

Another philosophy from Erlang:

This adheres to our general principle - we do not provide built-in mechanisms, we provide primitives with which mechanisms can be built(1)

i.e. perhaps a "batteries include" Actor library/framework isn't what is needed(2) but rather some message+state store that provides some functionality to schedule (single thread) execution via delivering messages (and isolated state) to behaviour( implementation)s - with an eye toward transparent message delivery to and from web workers.

1: Erlang provides the primitives, OTP implements the mechanisms.
2: In the same vein as: You don't need a library for state machines.
3: I'm aware of Comlink at the core of Clooney but Comlink seems more OO than message-oriented.