[chore] refactored guards internals to standardize built-in guard definitions and clarify logic flow

[Enteleform]

• fixed typo in error message
• added documentation for stateIn
• refactored evaluateGuard to clarify logic flow
• consolidated repeated definitions into LogicGuards type
• implemented abstractions to standardize built-in guard definitions
• added changeset

[changeset-bot]

🦋 Changeset detected

Latest commit: d7ca549

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

This PR includes changesets to release 1 package

Name	Type
xstate	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

[codesandbox-ci]

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

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[Enteleform]

If viewing commit: refactored evaluateGuard to clarify logic flow

Seems like the Prettier output changed some whitespace throughout the document for some reason. Go to the next comment for the actual updates 👇

[Enteleform]

If viewing commit: refactored evaluateGuard to clarify logic flow

Updates start here 🎯

[with-heart]

When adding a changeset, you want to document changes to the public api since those changes affect users and these entries are added to the changelog.

Basically imagine yourself as a user reading the changelog entry for this change. You'd want to know:

• what changed?
• why did it change?
• how do I use the change?

If there are no changes to the public api (I'm not sure), you shouldn't add a changeset.

[Enteleform]

Ah, gotcha. It was generated during step 7 of CONTRIBUTING #making-changes. The instructions don't give any criteria for when to include a changeset or not, they just say to generate one.

There are no changes to the public API in this PR. Do you recommend removing the changeset?

[Andarist]

I'm not the biggest fan of those changes to how guards are structured here. I don't see big issues with the current structure and I don't think this is a problem worth solving. it could also be seen as a breaking change (in quite an edge case scenarios but still). Also, the fact that each guard had its own "not callable builtin guard" with a unique .name that repeated the guard's name was very much intentional.

[Andarist]

I don't think we are going to proceed with this particular PR. I'm especially opposed to this change. Maybe some other changes from this PR could be pulled in but I don't feel a strong need for this either way. I'm sorry for closing this as I know that you put some effort into this - we really appreciate that!