search

mattpocock / xstate-codegen

A codegen tool for 100% TS type-safety in XState
MIT License
245 stars 12 forks source link

Support delays in machine options #54

Closed danielkcz closed 3 years ago

danielkcz commented 3 years ago

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

changeset-bot[bot] commented 3 years ago

🦋 Changeset detected

Latest commit: 50961395f658e361e8a74514b0273499cfb55012

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package | Name | Type | | -------------- | ----- | | xstate-codegen | Minor |

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

mattpocock commented 3 years ago

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.

danielkcz commented 3 years ago

@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

mattpocock commented 3 years ago

@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!

danielkcz commented 3 years ago

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.

mattpocock commented 3 years ago

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 :)

danielkcz commented 3 years ago

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 :)

danielkcz commented 3 years ago

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.