You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With Typegen in v4, we had no problems with events in actions. But in v5, we need to narrow event types to events manually (The corrent event types according to the places it has been used were provided by typegen). Well, it's managable.
But missing done/error events is a big problem at the moment. I have no idea how to provide the right event type to an action. Since the variables from done events of invoked services are in 'event.output' instead of 'event' (like it's in transition events), I cant't solve it by using a transition event with the same payload to fake it.
I'm curious why there's not a flattened Event object versus different types of events?
For example, why not something like:
type DefaultEvent {
id: string; // I think what is currently being sent as event.type is actually an identifier
type: 'default';
data?: Record<string, any>; // data passed to event from success could be standardized under a key like data
error?: Record<string, any>; // data passed to event from error could be standardized under a key like error
}
type ErrorEvent {
...
type: 'error';
...
}
type Event = DefaultEvent | ErrorEvent; // etc., discriminated union
It seems to me that the type being sent for events that result from onDone, onError, etc. are actually identifiers (i.e. xstate.done.after.index.machine.state) rather than pure types (i.e. "my-event"). A flattened event object would allow me to do something like:
type MyDoneEvent = DoneEvent & { id: 'my-done-event' };
And then from things like actions I could make sure my code is running against the proper event like:
@rmgryan I agree that event type on onDone/onError events is more like an identifier. Even a simple type: 'done-event' which is same across all onDone events allows me to do something like:
It's only correct to assume that everything can receive just any event type within
setup
and entry/exit actions, invoke inputs, etc.Events that are missing are done actor events, done state events, error actor events, xstate.init, xstate.after and probably more
The text was updated successfully, but these errors were encountered: