V5: Early Feedback and Discussion

[christoph-fricke]

I started to look into updating XSystem to support V5 as soon as possible when it arrives.

Therefore, Most of my feedback and questions are related to Behaviors and ActorRefs. I really dig the LifecycleSignals since they fix a long-standing issue in XSystem - not being able to cleanup resources on stop.

Instead of discussing this in Discord, I feel like this is a better place to open new questions/feedback by "answering" (GitHub term) this discussion, which can then be further discussed by replying to the "answers". Of course, other are free to joins and post questions/feedback as well. 😃

[christoph-fricke]

Topic: Spawning actors from Behaviors

In V4, it is possible to spawn an actor from a Behavior with spawnBehavior. This function appears to be removed in V5. The only alternative that I found is OberserableActorRef, which can be constructed with a Behavior.

Is OberserableActorRef the suggested approach going forward?

If I remember correctly, the spawn action will be removed in V5. Maybe a new function spawn can be exported that returns an ActorRef for either a Behavior or StateMachine by delegating to OberserableActorRef and interpret. Is the spawning process fully fledged out yet or am I joining the party too early? 😄
My main idea is to expose a unified function for creating ActorRefs at the top level (outside of a Behavior or StateMachine). Of course, the name is not set in stones and can be changed if it causes confusion.

[davidkpiano]

Is the spawning process fully fledged out yet or am I joining the party too early? 😄

You're a little early to the party!

One big thing I was thinking of is specifying how behaviors should start themselves. For example, with machines, it feels a bit awkward that there are two separate functions for a machine: createMachine(...) and interpret(...). Ideally, a behavior knows how it should be started, and this can be self-contained:

const machine = createMachine(...);

// instead of:
// interpret(machine, opts)
machine.interpret(opts).start()

[christoph-fricke]

Ideally, a behavior knows how it should be started

Why? I am not sure I fully understand the motivation behind your idea. I feel like it merges two concerns - defining behaviors and creating actors - and makes it less composable and extendable.

The only advantage I can somewhat image is the absence of a "runtime" in the sense that a behavior can control everything about actors spawned from its definition, i.e. mailbox implementation, subscriber management, keeping state between transitions, etc. However, if required it could also be achieved by implementing ActorRef directly and not Behavior.

At the same time, 95% of the use-case only need a unified default implementation, so a helper factory, which provides the spawning implementation for a behavior, is required to create something as simple as a behavior. Most likely it would look something like function createBehavior(behavior: CurrentBehaviorInterface): StartableBehaviorInterface, where RuntimeBehaviorInterface provides the initial value und transition logic and is combined with the default "runtime" implementation. At that point it does not feel much different from function spawnBehavior(behavior: Behavior): ActorRef.

What would be simplified, future-proofed, or enabled by this other than the visual difference between spawn(behavior) and behavior.spawn()?
I am still trying/hoping to find a solution that enables something like function spawnInWorker(behavior: Behavior): ActorRef, which would execute the behavior in a WebWorker. These custom APIs feel much more natural if spawning is not coupled to the Behavior interface.

[davidkpiano]

@christoph-fricke That's good feedback, thanks. So it makes sense that behaviors should not own its "runtime/interpretation" implementation.

So perhaps the solution is to allow for the interpretation of any behavior, not just machines:

// create standalone actor
const actor = interpret(someBehavior).start();

[christoph-fricke]

So perhaps the solution is to allow for the interpretation of any behavior, not just machines:

I would love to see a unified interpretation that treats behaviors and machines equally. When focusing on the actor layer, a machine is IMHO just another behavior that has been defined through a state-machine (or statechart) definition. Reflecting this in code as much as possible would be awesome.

[davidkpiano]

So perhaps the solution is to allow for the interpretation of any behavior, not just machines:

I would love to see a unified interpretation that treats behaviors and machines equally. When focusing on the actor layer, a machine is IMHO just another behavior that has been defined through a state-machine (or statechart) definition. Reflecting this in code as much as possible would be awesome.

Yes, exactly my thoughts.

In general, I want XState's "atomic unit" to be:

(state, event) => [nextState, effects]

The machine.transition(state, event) function encapsulates this pretty well, and there is nothing specific about how effects are executed (machine vs. promise vs. callback, etc.)

[christoph-fricke]

Topic: LifecycleSignals and Transition

Processing lifecycle signals in the transition method is awesome from a conceptual point of view and annoying at the same time. The alternative could be optional start and stop methods that behaviors can define, which are called instead when a lifecycle signal is processed from the mailbox.

I still have an inner conflict about my preferred approach. Hopefully, other thoughts and opinions can resolve this conflict... :)

Some of my thoughts regarding this topic:

1. The Behavior interface currently still contains an optional start method, which is never called or implemented in the rest of the codebase. Is it just a relict of the past or does it have an intended use case? Together with stop it could become useful. Otherwise, it should probably be removed.
2. Testing composed behaviors becomes more complex. Assertions about forwarding or not forwarding transition calls to wrapped behavior suddenly have to consider signals when the tests use actors. An example for such tests is this snapshot-based undo/redo behavior. While, signals should definitely be forwarded, suddenly many non-related tests has to consider them. Providing start and stop methods might make this more explicit while removing the concern from other tests.
3. I am debating with myself whether or not I should switch and test the behavior directly instead of the actor that is spawned from the behavior. It would avoid the problems that are described above. At the same time, not testing the behavior the same way it is used in applications allows for some bugs to slip through. For example, I would have missed a bug where the event-bus attempts to publish its lifecycle signals to subscribers, since every message received in transition is published.

I am really not sure about the correct approach and open for feedback. Explicit methods for transitioning lifecycle seem to simplify some things and allow the "event" transition focused on sent events. At the same time, handling everything in a single transition function might be conceptually cleaner.

Either way, I am more than happy to contribute potential changes and help "finishing" the story around behaviors and actors.

[Andarist]

This area is still WIP - we might consider minor refactors there to improve the ergonomics. Hard to tell what those will exactly be at this point in time, I will be revisiting this in the future. I would be happy to jump on a call some time to hash out some details and to go through the current implementation.

While, signals should definitely be forwarded

This seems a little bit off - unless I'm missing what kind of forwarding you mean here. Those signals should only be handled by a single behavior, of course starting one actor might lead to starting another actor but in such a case the child actor should receive its own signal.

[christoph-fricke]

Those signals should only be handled by a single behavior...

You are absolutely right. I was more or less referring to the behavior of the linked example. In hindsight, I did not clarify it correctly.

I am thinking about composed behavior or higher-order behavior, where the behavior wraps another behavior to enrich it with functionality, e.g. withHistory which can provide basic undo/redo functionality to other behaviors. After composition, they act as a single behavior, result in one spawned actor and receive one set of signals. However, for the composition to work, withHistory must forward received signals and events to the inner behavior, otherwise the wrapped behavior would not execute its potential starting and stopping code.

TLDR: Forwarding signals is required in a behavior that is composed of two+ behaviors forming an "onion behavior", where the outer behaviors have to forward signals to the inner behaviors. Or "Higher-order behavior must forward lifecycle signals".

I would be happy to jump on a call some time to hash out some details and to go through the current implementation.

I would be happy to to that and help wherever possible. :)