xstate
xstate copied to clipboard
statelyai
Removed TS troubleshooting sections
⚠️ No Changeset found
Latest commit: 1f78a07f2571166dd2a4f6ba1c74a6be79491a98
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
![changeset-bot[bot] avatar](https://avatars.githubusercontent.com/in/28616?v=4 "Published by a pub.dev verified publisher"){kind=small}
These troubleshooting sections have been solved by typegen, so we can remove them.
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 1f78a07f2571166dd2a4f6ba1c74a6be79491a98:
| Sandbox | Source |
|---|---|
| XState Example Template | Configuration |
| XState React Template | Configuration |
![codesandbox-ci[bot] avatar](https://avatars.githubusercontent.com/in/38409?v=4 "Published by a pub.dev verified publisher"){kind=small}
@davidkpiano I was thinking about this, but I'm not sure they are - if the official advice of the library is to 'use typegen', which fixes these problems, then it doesn't make sense to keep around detailed explanations of lesser solutions.
@davidkpiano I was thinking about this, but I'm not sure they are - if the official advice of the library is to 'use typegen', which fixes these problems, then it doesn't make sense to keep around detailed explanations of lesser solutions.
But there currently are situations where using typegen is not possible (different IDEs, CodeSandbox, etc.)
IMO, if the answer to the question "Is it possible for a user to run into these problems under normal usage?" is "yes", then the troubleshooting advice should still stay there. Removing it has, at best, a net-zero benefit for the user, and at worst, it's removed so they will inevitably ask for troubleshooting help instead of referring to the documentation.
Using XState without typegen should still be considered normal usage, at least for now.
@davidkpiano Agreed, maybe when we release the CLI we can ditch this.
I do think removing excessive documentation is a positive for the user. I.e. why have things on the docs site if they're not useful?
@davidkpiano Agreed, maybe when we release the CLI we can ditch this.
I do think removing excessive documentation is a positive for the user. I.e. why have things on the docs site if they're not useful?
That's a good discussion point (cc. @laurakalbag) - IMO, troubleshooting information is not read like normal docs. Users typically won't read through an entire troubleshooting section; they're likely going to just find (ctrl-f) the exact problem they're having.
In that case, having more troubleshooting info is much better than having less. Not finding the thing you're trying to troubleshoot is much more frustrating than thinking "there is too much troubleshooting info".
@davidkpiano Yes, though maybe we should present it in a different way - i.e. in an accordion or on a separate page.
@davidkpiano Yes, though maybe we should present it in a different way - i.e. in an accordion or on a separate page.
Good idea, maybe <summary><details>?