New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate accordion to xstate5 #1206
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
I appreciate the efforts you put into this @Devessier. Given the amount of work needed to make this work, I imagine it's quite overwhelming, and you might not have enough time to review all the components and examples. Let's put this aside for now and revisit this decision to migrate to XState later in the future. Thank you |
📝 Description
This is a PR to start migrating machines to XState 5. I start with the Accordion machine.
⛳️ Current behavior (updates)
Currently, the Accordion machine uses a custom XState-ish implementation for its state machine.
🚀 New behavior
Here, I use XState 5 and @xstate/react.
💣 Is this a breaking change (Yes/No):
No
📝 Additional Information
This is a first pass on the problem. I directly coded on the page of the Accordion machine.
Here are things that we can improve or should discuss:
value
andmultiple
properties from the context are listened to run thecoarseValue
function, which prevents thevalue
from reaching an invalid state. Instead of relying on a watcher, I run thecorseValue
function every time I assign a new value to thevalue
property, including when the machine starts (replacing thecreated
hook).setup
function from XState to strongly type the machine without needing the help of Typegen.CONTEXT.SYNC
which is sent from auseEffect
that listens to changes tocontrols.context
. ThecoarseValue
function is applied before merging the following context.getComputedContext
to resolve the computed properties. I searched but was unsure if these properties should be made available to the end user. They are only internal and resolved in theaccordionConnect
function.contextFakelyAugmented
as a trick to avoid being obliged to send computed properties to the dom functions, as it didn't seem required.assertEvent
function from XState to narrow the type of events in actions and guards. We might want to reimplement it so there isn't a cost in production.onValueChange
andonFocusChange
in the assign actions to update thevalue
andfocusedValue
properties. I would have preferred to call these functions in a separate action rather than inside theassign
action, but it would have caused more headaches than necessary.