Allow invoking interpreted machines

[RonaldTreur]

Proposal

The invoke-property currently allows for the following values:

• Promises
• Callbacks
• Observables
• Machines

I would like to add another option:

• Interpreted Machines (aka Services).

State of a Service

There are two possible states of the invoked service:

1. the machine was interpreted but has not been started
   e.g. const serviceToInvoke = interpret(childMachine)
2. the machine was interpreted and the resulting service was started
   e.g. const serviceToInvoke = interpret(childMachine).start()

If the service was already started, fine. But if the service has not yet been started, then upon invoking it, it should immediately be started.

The data-property

Currently, when a Machine is provided to invoke, an optional property data is available to allow the context of the invoked machine to be primed with data from the parent's extended state. See the example below:

invoke: {
  id: 'timer',
  src: timerService,
  // Deriving child context from parent context
  data: {
    duration: (context, event) => context.customDuration
  }
}

The question is how to deal with this property when a Service is being provided instead? See the following three options:

1. It will be ignored (since it is Machine only)
2. It would only be applied to services that have not yet been started
3. It will be applied to all services (by assigning it to interpreted machine's context)

I would think option 3 would be optimal as it gives the most flexibility and has not real disadvantages (as far as I can see). It could potentially be made even more powerful by also providing the context of the (invoked) interpreted machine as an additional argument to this function. Then one could really finetune how the interpreted machine's extended state should look like after having being invoked.

Upon leaving the parent's state

With machines, leaving the state in which the machine was invoked, would stop the (under the hood) interpreted machine's instance. The question is wether this should also occur when a service was directly invoked. A case could be made for when the service had not been started yet before it was being invoked, to follow this behavior. When the service was already started however, this might not always be preferred.

To keep things simple, I would have no objection to the service being destroyed upon leaving the associated parent's state. However, my preferred solution would be to instead implement some mechanism by which the invoked service would be notified and allowed to act on itself.

I have no exact mechanism for this in mind at this moment however.

[RonaldTreur]

So why this proposal?

I stumbled upon this while trying to get a web component to spawn a complicated dialog (a different component) to retrieve the user's input.

Every web component has its own state, so owns and operates its own interpreted machine. Since the appearance of the dialog is however fully dependent on the current state of its parent-element('s state), it felt right to use invoke here. The dialog starts out in a hidden state, and upon being invoked would then switch to an active (visible) state.

If the user leaves the parent state that invoked the dialog, it should disappear, which is an "automatic" behavior with invoked Machines, that could be (somehow) extended to Services.

All that is clearly not working at the moment (V4), requiring the use of some hacky work-arounds instead, hence this proposal.

[davidkpiano]

Thank you for the proposal write-up. I feel like we should limit this proposal to only invoked and started services (interpreted machines).

The problem with "the machine was interpreted but has not been started" is - what if two separate services invoke the same machine at the same time? Do they both start them? Do they both have ownership? How does this affect data etc.

Already started services should have the parent that they were created with (actors can't "change" their parent in the same way that we can't change our biological parents).

Also, we shouldn't assign data directly to the started service's context because 1) that breaks actor state isolation, which leads to a whole host of problems, and 2) same issue as before - if multiple machines invoke that service, will they just keep overwriting the context? Race conditions can happen there.

But yes, the minimal viable behavior should be that some service should be able to communicate with an existing service by "invoking" it. That existing service can communicate back by using respond(...), which already exists, but not sendParent(...) since the invoking service is not the existing service's parent.

[Andarist]

I agree with @davidkpiano's concerns and I don't think we should anyhow affect such invoked services (for example with data) and that if you want to "invoke" a service then this should be limited to already started services as other options don't make much sense from the actor model etc POV.

I'm not sure though why you would like to have this option though - why do you want to "invoke" such a service, rather than, for example, just put it into initial context? As we don't want to really start such services when entering a specific state nor we want to bound its lifetime to that state, I don't get why the invoke is needed for this at all. Could you elaborate more on the use case? Either way - in the upcoming v5 you would be able to do this as you would be able to create a wrapper actor interface over existing services to achieve this, but I'm not sure if one should do it.

[RonaldTreur]

Thanks @davidkpiano , you raise some valid concerns! Coming at this from a completely different (more narrow) perspective, I hadn’t thought of those. If that is how things will work, I can live with that. That is clearly the easiest and least complex way of allowing services to be used.

That said however, if it would be implemented the way you describe, then I believe there is almost no benefit anymore to invoking an existing service compared to interacting with a non-invoked one. All that is left are the slightly more convenient inter-service communication options like respond(...) and onDone: {...} (assuming that will still work).

In your mind, what would then be the reason doing this would make sense?

I realize you have the whole idea about how you want to deal with actors (in V5) in your head, so I hope you could help me shed some light on the use case I am coming from:

---

1. My application consists out of web components. Each of these components has its own interpreted machine
2. Every component is an actor
3. There is a clear parent-child relationship between nested web components

Now I think here is where our ideas may start to differ: I see a web component and its interpreted machine as the same actor. They are tightly coupled because the whole behavior of the component is directed by its state machine. In fact, besides having a way of being represented in the DOM, the statemachine is really what defines the component.

There is a clear parent-child relationship on a DOM-level, but this does not extend to the interpreted machines inside of the DOM elements. However, state machines also have support for child services in multiple ways. Of course partly to manage the state of sub-logic that is not represented by a different actor, but with invoke there is a clear way of setting up a relationship between two actors.

Perhaps this is simply a red herring to me.. but I am looking for a way to hook both these services up in a way that makes their relationship clear as well as provide the added benefits of having this relationship (all the niceties that come with an invoked service).

---

I can come up with several ways of doing that, that would also alleviate your rightful concerns (multiple "parents" trying to invoke the same service & race conditions).

For example (and this is probably a bad idea that makes things far too complex): What if a service could be designated invokable? In which case a single other service could claim (partial) ownership for a while. Once claimed, no other is allowed to do so until ownership has been relinquished.

Just a rough idea to keep the conversation going ;-)

[Andarist]

In more traditional actor systems "everything is an actor". This has a consequence of actors always being invoked by other actors - there is just no way to spawn an actor "out of thin air".

I'm not well-versed in web components API (I know the concept though) so I would like to talk about a more concrete situation using React app as a base. It's also component-based so I would really expect both systems to have very similar traits and possibilities.

I think we can distinguish 2 main situations possible:

1. you have a machine that invokes another machine and only then the associated component gets rendered as well (parent-child relationship is clear)
2. you have separate pieces of UI which have their logic machine-based and you need to communicate between them even though the parent-child relationship is not clear as both seem orthogonal to each other

From what you are saying I assume we are talking about the first situation here and I think we can go about implementing this in two ways:

1. keep logic of both near the parent and just treat a children component as sort of a template which gets rendered based on the passed down data
2. keep logic of each component+machine pair together

There doesn't seem to be much of a problem with the first approach as the whole logic just lives in a single place~ and I don't see any potential concerns/doubts one could have about it. I understand though why you would like to use the second approach - it definitely has its merits thanks to better colocation of logic & rendering concerns.

Knowing that we are looking only at parent-child relationships right now - it should be easy to just export a machine and a component separately from the child so the parent could both invoke that machine and render that component in a very natural way. While doing this you would have to pass the created children service (accessible in state.children) to the child component as a "prop" so it can use it appropriately (render based on state and also send events to it, etc). This is what I would do in React using useMachine in the parent and useService within the child.

Does this solve your concerns? Have you envisioned the glue code between those 2 differently? What kind of problems do you see with the proposed approach?

[RonaldTreur]

Hi @Andarist, thank you for your elaborate response!

From what you are saying I assume we are talking about the first situation here

You are correct. It deviates however slightly from how you describe it, though that might not be really relevant for this discussion. But just to clarify nonetheless: It would be great if a machine could be invoked before rendering the associated web component. That is however impossible to do with web components.

At the moment (in my code), a machine is being interpreted in the constructor of a component. Unfortunately, a web component’s constructor does not allow* any custom parameters, so it is not possible to supply it with the service that results from an invoked machine at that stage.

*) not entirely true, but as they are most often being constructed by inserting HTML (as text) directly into the DOM, there is no way to supply data to the constructor. At the very least this means any arguments should always be optional.

1. keep logic of both near the parent and just treat a children component as sort of a template which gets rendered based on the passed down data
2. keep logic of each component+machine pair together

There doesn't seem to be much of a problem with the first approach as the whole logic just lives in a single place~ and I don't see any potential concerns/doubts one could have about it. I understand though why you would like to use the second approach - it definitely has its merits thanks to better colocation of logic & rendering concerns.

Your last sentence is exactly why I started this discussion indeed :-) I would very much prefer option 2.

Knowing that we are looking only at parent-child relationships right now - it should be easy to just export a machine and a component separately from the child so the parent could both invoke that machine and render that component in a very natural way. While doing this you would have to pass the created children service (accessible in state.children) to the child component as a "prop" so it can use it appropriately (render based on state and also send events to it, etc). This is what I would do in React using useMachine in the parent and useService within the child.

That is more or less how I am solving things right now. The parent imports the Machine and creates the child component. It then invokes a new service with the machine and indeed supplies the service via a property to the component.

Does this solve your concerns? Have you envisioned the glue code between those 2 differently? What kind of problems do you see with the proposed approach?

This does solve my problem, but exactly because I feel that this use case is (or will be) pretty common (for those of us working with web components, or a framework built on top of them) I created this discussion (well, David asked me to do it over here). I would like to see this go a little smoother and I would like (as you mentioned) that the component creates its own service (and hence could also operate independently).

For example, it could be ”solved” like this:

1. Upon being constructed a web component would interpret its own machine
2. Upon being inserted in the dom (connected), it would dispatch an event containing its service
3. The parent component would pick it up and invoke it, solidifying the parent-child relationship on the state machine level as well.

A few notes:

• A component would only dispatch an event (2) with its service if it has to, or optionally can be used as a child to a parent (let’s say it can be adopted). Most components should probably be able to function in isolation, due to the nature of HTML and web components.
• Going from 1 (constructed) to 2 (connected) would imply a state change, hence the firing of this event (2) could be done with an entry action.
• One could also decided to postpone interpretation of a component’s Machine to the moment it is being connected, but that is up to the developer. It could be more efficient to lazy load it when it needs to become active for the first time.