Replace getters on MachineSnapshot with methods
#4467
Conversation
🦋 Changeset detectedLatest commit: 0d0a0f9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 0d0a0f9:
|
| /** | ||
| * The next events that will cause a transition from the current state. | ||
| */ | ||
| getNextEvents: ( |
There was a problem hiding this comment.
One thing that I'm not that fond of here is the name of this. getNextEvents name doesn't match what is returned from this method. What other options do we have on the table? 🤔
There was a problem hiding this comment.
I was going to get rid of this and have a getNextTransitions function instead.
There was a problem hiding this comment.
Flat map of own transitions of all state nodes
There was a problem hiding this comment.
I'm not sure if that would be that helpful in practice. Or at least that it opens up the return value in a way that we perhaps don't have to. I know I'm a broken record but IMHO such a public piece of the API shouldn't expose things such as guards and actions to people. For most purposes those are really implementation details and we should steer people towards solving their needs in different ways. I don't want to neglect the introspection needs but that can be solved with a dedicated API - the user would have to do the introspection more explicitly.
But even putting those concerns aside, I think that a runtime API like this should at least account for forbidden transitions. This isn't currently solved by the nextEvents API either so there is that but I think that it's sort of a footgun. If the primary use case of this is to generate the UI dynamically based on this then we should account for this because it's so easy to forget about it. Even transition shadowing is a problem here (a: { on: { FOO: {} }, states: { a1: { on: { FOO: {} } } } }). If we don't solve problems like this then what's even the purpose of this API? I'd like to think that the users know how to flat-map things and that this alone isn't a strong reason to introduce an API. Especially that the audience for this is limited - most users certainly don't care about this.
All in all - providing a flat list of transitions/event descriptors isn't solving a meaningful problem, I think. Hierarchy is baked into XState and IMHO APIs like this should account for it. The introspection API wouldn't solve this completely either but I think that with an API like this, it's way more apparent to the user that they are interacting with something special and that they might have to stitch more things manually to achieve what they want. The introspection API might intentionally be quite "raw".
* state.configuration -> state.nodes * Changeset * Rename Machine -> createMachine and .nodes -> ._nodes * Rename Machine -> createMachine and .nodes -> ._nodes
closes #2498