@jancewicz Yes, something like that. In v6, there will be much fewer inferred types to worry about, so we can definitely improve the DX around "modularizing" a state machine.

Indeed, having some kind of reusability becomes a must once the project becomes large and you start repeating yourself a lot between your machines. BTW do you guys have some idea how to mitigate the consequences of having a single shared context between states (besides being careful when designing your states and transitions)?

Hey@davidkpiano,

Can you share more about your solution? We're working on XState v6 and I want to see if there are some parallels between what we're planning and what you came up with.

Of course. Here are the core features I wanted to achieve:

1. Type-safe context: For any given state, the context shape must be known precisely.
2. Type-safe machine definition: No room for errors when declaring states, events, transitions, or handlers.
3. Reusability of modules, including:
   • Logic (actions, handlers)
   • States
   • Events

I built a system based on two principles:

1. Each state is responsible for constructing the next.
2. Each state is an independent module.

To make this work, each module’s handlers are implemented as factory functions that accept the dependencies they need. This decouples handlers from both the previous and next context shapes.

Here's a simplified version of the approach (in practice, everything is fully type-generic):

typeNewState={name:string;context:Record<string,unknown>;};typeCreateNextStateFn=(handlerResult:Foo,previousContext:Record<string,unknown>)=>NewState;functioncreateHandlerFoo(createNextState:CreateNextStateFn){return(event:FooEvent,context:Record<string,unknown>)=>{constresult=handlerFoo(event,context);returncreateNextState(result,context);};}constmachineDefinition={[STATE.FOO]:{events:{[EVENT.DO_FOO]:createHandlerFoo((fooResult:Foo)=>({name:STATE.BAR,context:{bar:fooResult},})),},},[STATE.BAR]:{events:{[EVENT.DO_BAR]:createHandlerBar((barResult:Bar)=>({name:STATE.FOO,context:{foo:barResult},})),},},};

The main difficulty I encountered is sharing data between distant states, since there is no more shared context. Currently, I'm drilling/accumulating on each intermediary state, but it's far from ideal.

Would love to hear your thoughts. Also curious how you're approaching this kind of modularity and type safety for V6.

@davidkpiano Just checking-in. I'm really curious about your input. I'm not satisfied at all with the context drilling. I'm curious about your thoughts on this.

@RemyMachado The tentative solution that I'm working on for XState v6 is doubling down on thetypestate (discriminated union) approach, with explicit schemas:

// TENTATIVE FUTURE APIconstcontextSchema=z.object({userId:z.string().nullable()});constmachine=createMachine({schemas:{context:contextSchema},// ...states:{userLoaded:{schemas:{context:contextSchema.extend({userId:z.string()})}}}});// ...if(state.matches('userLoaded')){state.context.userId;// string}else{state.context.userId;// string or null}