Software engineer @avec_alan (opinions mine) | ex @Shopify | Tool Maker
| #SoftwareCraftsman
| C & Test lover
| Web Metamodernist
| Author of PicoTest, Colibri and Seaborg
Great article, thanks! Another (major IMHO) argument in favor of useMachine over useState/useReducer is that the latter both depend on useEffect hooks that are a potential source of race conditions with asynchronous code. See for example:
Another big win for XState is that the machines are framework-agnostic. This means you can share the same your state logic across codebases (front/back/etc) and reuse the code in case your technical requirements change (e.g. front-end framework).
Self-documentation is the cherry on the cake.
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.
Great article, thanks! Another (major IMHO) argument in favor of
useMachineoveruseState/useReduceris that the latter both depend onuseEffecthooks that are a potential source of race conditions with asynchronous code. See for example:flufd.github.io/avoiding-race-cond...
joel.net/beware-of-reactuseeffect-...
Another big win for XState is that the machines are framework-agnostic. This means you can share the same your state logic across codebases (front/back/etc) and reuse the code in case your technical requirements change (e.g. front-end framework).
Self-documentation is the cherry on the cake.