Add support for MachineOptions.actions reference in invoke.data

[ayashjorden]

Hi,
In my use-case, there’s no MachineConfig coded anywhere, its being provided as part of a request to my micro-service API, then I take this payload and pass it to the MachineConfig constructor to create the config.
When the user is POST-ing a JSON payload (application/json), the user cannot pass a function as part of it as JSON does not support that.

Consider the following MachineOptions:
(This is provided in my micro-service)

{
    actions:{
        inheritParentContext: (c,e) => c
    },
    services: {
        someServiceName: Machine(....)
    }
}

The following MachineConfig block will call the inheritParentContext action and assign the result to invoke.data
(This is provided by the user as part of a POST request to my API to create the machine)

{
    ...
    "states":{
        "invokeWithActionReference": {
            "invoke": {
                "id":"invokeId"
                "src": "someServiceName"
                "data": "inheritParentContext",
                "onDone":....
                "onError"....
            }
        }
    }
}

Thank you,
Yarden

[davidkpiano]

I'm a bit confused, you want data to be determined from the inheritParentContext action? Actions do not go on the invoke.data property.

[ayashjorden]

Yes, this is why its a feature request.
As explained, my users provide the MachineConfig as POST request payload and the invoke.data in its current implementation will allow them to set that to static data, while I have several use-cases where the child-machine needs access to the parent-context.
The child machine context may need be also computed.

WDYT?

[ayashjorden]

In the mean time, I'm rendering the MachineConfig through a Factory to replace with the Action function ref

[davidkpiano]

Relevant issue: #361

[ayashjorden]

Ok, so I understand that rendering the MachineConfig is the only solution ATM.

Thank you

[davidkpiano]

I'll look into further supporting "selectors" in V5.