Using XState for Collaborative Frontend Development and State Management

Background: The article describes a complex image‑text/video mixed page with many interactive components. Traditional component‑wise development caused high maintenance cost for a few core engineers. To improve collaboration, the team adopted the open‑source XState state‑machine library after researching cases, source code and literature.

XState theoretical basis: Before XState, the team sought a \"code as process\" model to lower upstream‑downstream coordination cost. Research led to the W3C SCXML standard (based on executable UML) and then to XState, a mature JS implementation with tooling that allows business logic to be expressed graphically.

xstate library basics: The core method createMachine receives a StateNodeConfig and returns a StateNode. StateNodeConfig properties such as actions and invoke define behavior. Example state configuration for a simplified like button:

states: { like: { on: { CLICK_LIKE: { actions: (ctx, e)=> console.log('you clicked to undolike'), target: 'undoliking' } } }, undolike: {}, liking: {}, undoliking: { invoke: 'requestToUndoLike', onDone: { target: 'undolike' } } }

Node attributes: actions can be strings, built‑in creators (send, assign) or anonymous functions; invoke is used for side‑effect services and provides onDone/onError callbacks. Parallel states allow orthogonal regions, e.g., a page machine with parallel sub‑states.

Transitions: XState declares transitions via the on attribute or the always attribute. on requires an event; always fires unconditionally. Conditions (cond) can be strings looked up in guards or boolean functions.

Tooling and usage: Visual editor plugins let designers draw state graphs; the simulator (xstate‑viz) sends events via WebSocket to observe state changes. In the Xianyu project, a custom WebSocket server was injected into the Flutter‑based kun container to enable two‑way communication with xstate‑viz.

Performance issue: Initial use of useMachine caused frequent re‑renders because actions (e.g., logging) generated new state objects even without state transitions. The team solved this by using useSelector to subscribe only to specific context fields, reducing renders to when those fields actually changed.

const MyComponent = (props) => { const [propa, propb] = useSelector(pageMachine, (state)=> [state.context.propa, state.context.propb], (a,b)=> a.length===b.length); return
{propa}
; }

Conclusion: With XState, only 1‑2 core engineers maintain the state graph while component developers work on lightweight UI pieces bound via minimal data contracts. Future work includes enhancing tool readability and adding graphical unit‑test support for more efficient collaboration.