Closed danielkcz closed 3 years ago
Latest commit: 50961395f658e361e8a74514b0273499cfb55012
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
This is great.
One thing which I had to double-check in my head: delays are not like entry actions. In a condition triggered by a delay, there's no event
which we need to type in order to get right.
@mattpocock Is is that important? I mean I tried what kind of event is happening there, but it's just an internal one.
https://codesandbox.io/s/tender-bush-9kuz0?file=/src/index.ts
@FredyC You're right. To clarify above, I was saying it wasn't something we needed to take into account. It's an internal event we can feel free to not type strongly.
Still early here!
Ah, totally misread you :) But in a way, I suppose it could be at least typed to AnyEvent
, right now it's never
which is technically incorrect.
I think never
is actually better than AnyEvent
, since you're never likely to want to use that internal xstate event. If that changes, we can revisit this. Happy to merge this, nice work :)
Alright, makes sense. I kinda managed to generate this locally, but that's not correct either because the name of the event should have the actual number, not the name of delay. I guess that would be more complicated and probably not worth it.
delayedCond: (
context: TContext,
event:
Extract<TEvent,
| { type: 'xstate.guard' }
| { type: 'xstate.after(REQUIRED_DELAY)#(machine).idle' }
>
) => boolean;
Merge away :)
Actually, I had the wrong example. With the named delay, the name is used in the event name. But obviously, users would need to include such a specific event in the machine events and that's unlikely someone would do, cannot even imagine the reason.
That wasn't as hard as I expected, you have the solid groundwork in there. Hopefully, I did not miss something, but tests are passing.
Fixes #53