Actor DX Questions

[derek-duncan]

I've done quite a bit of experimenting to see how actors would work on a large scale. Here are a couple things that keep coming up I wanted some input on. This is not criticism but questions popping up from implementing the dream in practice ✨

1. Debugging. When an event is dispatched and forwarded between many actors, it gets pretty tedious to trace the flow of events and to replicate the timing of dispatches coming from many actors. This is one place where React's ui = fn(state) can feel like a simpler representation than a statechart when debugging. I think microservices have the same difficulty with event sourcing..
2. Wiring Up. Actors need to know about each other to dispatch events back and forth. There's a fair amount of wiring up to get dispatches pointed in the right direction... like a card house. With a whole app of actor refs passed around, a lot of dev work is around wiring (part of struggle is DX of service.children right now). Benefit of redux was a central dispatch. With actors (esp many actors), there's a mental load of passing the right ones around. Again, the React ui = fn(state) feels comparatively simple.
3. Refactoring. Have you experienced many issues with refactoring a statechart-heavy application? The top-down approach makes things pretty rigid to rework, especially when actors are redesigned. I know there are benefits to top-down.. just wondering if you have any tips from experience in the refactoring process.
4. Global State. Some global state like authentication info must be passed deeply through all child actors. How is this best handled when you have a tree of actors communicating between one another? It feels wrong for every child to have context.user for instance.. like determining user permissions on many sub-features.
5. Still declarative?. Like mentioned before, React is in essence ui = fn(state). It's very simple. You can definitely feel the rub with putting actors into this paradigm (detecting what state changes and when). It becomes difficult to still update your UI in a declarative way like React does elegantly.
   When I think of other UI libraries that align with actors better, I keep thinking of jQuery days with all the event handlers and imperative updates: when an event happened, you manually changed all of your UI in the handler. We unfortunately did not have a statechart representing the states these event handlers could be in then, but regardless, the UI is still updated with actors in the same imperative way. Instead of UI updates being declarative, it's now the state transitions that are declarative — tradeoffs I suppose.
   The downside of imperatively updating your UI with event handlers (within actors) are that UI updates come from everywhere, instead of top-down from state. As actors grow and event dispatching increases, the app is updated through many "imperative" changes from many actors, and it definitely can feel less one-way than React's simple one-way model. You can see people trying to simplify UI updates by turning their statechart into their "React state" when they render from current.matches('myState') instead of semantically dispatching actions to imperatively change the UI. As React JSX demonstrated, UI updates are much better represented declaratively than direct DOM manipulation.
   Do you see this tradeoff in declarative UI updates a downside? Any patterns to help with this issue?

There are many things better with actors too (which I can list later) 😄

tldr; how do we avoid microservice issues that other engineering environments have struggled with and preserve the benefits of declarative UI updates.

Eagerly awaiting your response. Thanks!

[davidkpiano]

Thanks for this write-up; this would make good documentation, so I'll take some time to answer these, and welcome others to answer these questions as well, as they are not specific to XState but rather common questions with microservice architectures, as you've mentioned.

[derek-duncan]

About items two and four, we discussed some ideas in the chat with using event busses and messaging/subscribing to spawned actors.

[derek-duncan]

More information and discussion around two and four in this post.