Really great article! I love to see XState being used out in the wild.
One thing you should probably note is that the machine input into useMachine is only interpreted once and is not reactive to any configuration changes. This means that even though you input a machine with different configuration, the result from useMachine wonβt have your updated sellable or purchaseHeaders(I learned this the hard way).
Instead, you can use two useEffects to listen for when sellableSlug and userId change and send explicit CHANGE events to your interpreted machine. This may also help make things more predictable.
This may have been resolved from the last time I inspected the source, so take my suggestion with the smallest grain of salt.
You're correct - the way state machines work is via events, and events only, which makes them much more predictable than a machine arbitrarily "changing itself" at any time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Really great article! I love to see XState being used out in the wild.
One thing you should probably note is that the machine input into
useMachine
is only interpreted once and is not reactive to any configuration changes. This means that even though you input a machine with different configuration, the result fromuseMachine
wonβt have your updatedsellable
orpurchaseHeaders
(I learned this the hard way).Instead, you can use two
useEffects
to listen for whensellableSlug
anduserId
change and send explicitCHANGE
events to your interpreted machine. This may also help make things more predictable.This may have been resolved from the last time I inspected the source, so take my suggestion with the smallest grain of salt.
Otherwise, this looks really awesome!
You're correct - the way state machines work is via events, and events only, which makes them much more predictable than a machine arbitrarily "changing itself" at any time.