XState v5 TypeScript improvements #2323

davidkpiano · 2021-06-21T18:02:08Z

davidkpiano
Jun 21, 2021
Maintainer

Let's discuss potential upcoming TypeScript improvements to XState v5 and how we might be able to implement them (cc. @devanshj):

Types for context, events, actions, guards, actors, delays should be able to be inferred from .schema
.initial property should autocomplete key from .states
Granular error if .initial property is not key from .states
States that are not .type: 'compound' (implicit or explicit) should not have a .states property
Actions, guards, actors, delays, etc. should be strongly typed throughout states + autocomplete
onDone should have its .data strongly typed for invoked promises
(todo: add more asks)

devanshj · 2021-06-21T19:28:18Z

devanshj
Jun 21, 2021

0 replies

devanshj · 2021-06-23T10:34:59Z

devanshj
Jun 23, 2021

Better `schema`

Okay so here are my thoughts on schema. First we must ask ourselves why the fuck does it even exist, well many reasons, mainly the one which @Andarist rightly points out that they're are a way for the user to create "contract" for the machine.

But my problem is it's way too compulsive. Well sure one might say they're optional - but they're not, in that the user need to provide types in some cases (like event payload) to have proper DX. What my pain point is it's kinda at odds with the whole philosophy of txstate, I'll try to show some scenarios how and at the end will give some suggestions on how we can have the users make a contract but at the same time it's not compulsive for the one's who don't want to and yet they won't miss out on the DX.

Story with event
Let's say I'm someone who is not interested in making a contract first hand, I want it to be inferred. Great, txstate can infer events from the keys of on. But how do we infer payloads? The user needs to define them. Now let's say the user only want to fine the payload for the ones that have one. Meaning let's say there are 8 events, out of which 7 don't have a payload. The user doesn't want to write { type: "E1" } | { type: "E2" } | ... | { type: "E8", foo: number}, they just want to somehow define that payload of E8 is { foo: number }, that's it and rest should be inferred and assumed to have no payloads. This at the moment isn't possible with schema.

Story with action
Let's say I'm again someone who is not interested in making a contract first hand, I want it to be inferred. Again, txstate can infer the action type from the things like entry: "foo", in this case it'd be { type: "foo", exec: whateverTheTypeShouldBe }. No problems here, except in case of an assign action we need the user to tell us the return type for inferring typestates, only the parameters of whateverTheTypeShouldBe are fixed. So again we have a similar problem that not all actions would be assign actions, so the user should be able to bail out of typing the other actions explicity. Moreover let's say an action isn't assign but the user still wants to type it like so { type: "bar", exec: (context: any, e: { foo: number } } => void } now if entry: "bar" is written and bar would never receive { foo: number } than we'd show red underlines at "bar" BUT the user would like to "merge" this type whateverTheTypeShouldBe as in have actual context and event based on the fact it's used at entry: "bar". Though again schema doesn't allow selective typing, it's just all or nothing.

Also if I'm not mistaken the assign actions resolves to { type: "xstate.assign" ... } so the "name" of the action is no where in the type.

Moreover, unless I've misunderstood schema.actions, it'd be utter madness to precisely type every action (and other things) in case of txstate xD I mean txstate fine tunes and narrows both context and event based on the location of action, even for those who want a contract, I doubt they'd want to take the pain of typing all actions so precisely. With txstate most of the contract gets defined on it's own.

I'm sure the story with other things like services, activities, etc would be similar though I haven't taken a concrete look.

Look, I understand the point of schema and making a contract but with these drawbacks taken into consideration I'd reframe the problem that schema solves something like this...

Inference sometimes can be a foot gun, meaning if you make a typo, the typo gets inferred. While writing keys of on and using named actions, guards, services etc we need to provide a way for user to name them beforehand in one place so they can save themselves from this typo problem. Though this should be opt-in and not compulsory for the following features.
We also need to allow users to define the requirements of a named delegation. Meaning for a gaurd "isEnterKey" the user should be able to define that it expects the second parameter to receive something that extends { keyCode: number }, so that when it's used for a transition that doesn't satisfy this requirement we can show red underlines on guard: "isEnterKey". Again inference would have been a footgun that if the requirement would have been never defined then the type of isEnterKey would have been inferred something unexpected and then the person writing the implementation of it finally will have the problem. So instead of the author of machine receiving an error, the author of the implementation of the guard would receive an error. So Mateusz was spot on when he said "inference creates type contracts of its own" and that we need a way to define an explicit contract of our own.
We need to allow a way to "merge" the inferred type and the explicit type provided. So for example, for an named assign action "updateEmail" the user just wants to type what's being returned and wants the parameters get inferred from usage. So the user would pass () => Assign<{ email: string }> but would want the final type to be (context: InferredContext, event: InferredEvent) => Assign<{ email: string }> instead.
Merging should be opt-in and not compulsive. Because it's possible the user doesn't want the merging. For example in case of "isEntryKey" when user writes the type (_: never, e: { keyCode: number }) => boolean they don't expect it to become (context: InferredContext, event: InferredEventThatHasKeyCode) => boolean). Why? Because let's say the user doesn't want the author of the implementation of isEnterKey to use the context or other properties of the event.

Now here's the solution to all these problem...

createMachine({
  schema: {
    events: {
      types: ["KEYDOWN", "BLUR"],
      // in case of `types: undefined` they are inferred
      payloads: {
        // user can have `payloads` even if they didn't define `types` because they will be inferred
        KEY_DOWN: t<{ keyCode: number }>()
        // the events missing are assumed to have no payload
        // meaning writing `BLUR: {}` would have the same effect
      }
    },
    guards: {
      identifiers: ["isEnterKey", "isShiftKey"],
      // in case of `identifiers: undefined` they are inferred,
      // user can have `definitions` even if they didn't define `identifiers` because they will be inferred
      definitions: {
        isEnterKey: t<(_: never, event: { keyCode: number }) => boolean>(),
        // the final type of isEnterKey is exactly the one which is defined
        isShiftKey: t.constraint<(_: never, event: { keyCode: number }) => boolean>()
        // the final type of isShiftKey is what gets inferred
        // though it has to match this constraint or else we'd show error at `guard: "isShiftKey"`
        // hence the final type is sort of a "merge" of both
      }
    },
    // other things would be same as guards
  }
})

declare const t:
  & (<T>() => { t: T })
  & { constraint: <T>() => { "t.constraint": T }
    }

Problem 1 gets solved now because users can define event.types and namedDelegations.identifiers and save themselves from typos. And it's not compulsory to write them in order to define their types as if the user omits writing all types or identifiers they get inferred.

Problem 2 gets solved because now you can write the types in definition.

Problem 3 & 4 gets solved by making two different things - t and t.constraint. Former makes the final type as defined by the user and latter gives a way to only define the minimum requirements of the implementation and hence puts a constraint on the inference.

Though there's one drawback. Let's say the user writes...

identifiers: ["x", "y", "z"]
definitions: {
  x: t<() => void>()
}

Here let's say they purposely left y to be inferred but wanted to type z but forgot. To solve this we could require explicitly defining all of them on a flag (we'll see where to keep it) so that they don't unintentionally leave out some, it'd look like

identifiers: ["x", "y", "z"],
definitions: {
  x: t<() => void>(),
  y: t.inferred(),
  z: t<() => void>()
}

My impression of the current schema is that it's just a better way to provide the TContext, TEvent, TAction, etc generics rather than something well thought that solves the problems at hand, pretty sure we can do better, can't we? ;P

Edit 1 -
I realised we also need a way for user to define the meta data for things like gaurds, actions, etc. The can do that by typing the third parameter. I know it's a little awkward but I think it's kinda consistent with the overall approach.

createMachine({
  schema: {
    guards: {
      definitions: {
        validateInput: t.constraint<(
          _: never, __: never,
          m: { guard: { inputType: "input" | "email" | "number" } }) => boolean
       >()
      }
    }
  },
  initial: "a",
  context: {}
  states: {
    a: {
      ON_CHANGE: {
        target: "a",
        guard: {
          type: "validateInput",
          inputType: "foo"
          // Error: "foo" cannot be assigned to "input" | "email" | "number"
        }
      },
      ON_FOO: {
        target: "a",
        guard: "validateInput" // Custom error: inputType is required
      }
    }  
  }
})

The third parameter also happens to have state, it goes a little overboard but the user could event define the state in which the guard can used. Not sure if it's useful but can be done, for example -

createMachine({
  schema: {
    guards: {
      definitions: {
        checkFoo: t.constraint<(
          _: never, __: never,
          m: { state: "a" }) => boolean
       >()
      }
    }
  },
  initial: "a",
  context: {}
  states: {
    a: {},
    b: {
      ON_CHANGE: {
        target: "a",
        guard: "checkFoo" // Custom error: checkFoo cannot be used in state "b"
      }
    }
  }
})

Edit 2 -
Okay so I figured out a way to make the api simpler at the same time solving the problems. Here's a narrative explanation of how the current api came into being, and here's a simpler version

guards: {
  $$exhaustive: true
  isEnterKey: t<(_: never, event: { keyCode: number }) => boolean>(),
  isShiftKey: t.constraint<(_: never, event: { keyCode: number }) => boolean>()
  isFoo: t.inferred()
}

Now instead of writing all identifiers they can just set $$exhaustive: true (we can even export a symbol if we don't want to reserve "$$exhaustive" as an identifier). Alternatively if we want the default behavior to be exhaustive users can set $$exhaustive: false instead when wanting other identifiers to be inferred.

0 replies

devanshj · 2021-06-24T21:21:27Z

devanshj
Jun 24, 2021

Critic: Why it should have been `({ context, event }) => x` instead of `(context, event) => x` and is it worth fixing it?

I know I know another critic xD but believe me I'm doing it in good faith! I want to show how we're losing features because of it and maybe it could be worth a breaking change.

Problems with `(context, event) => x`

1. Can't write a type gaurd for both context and event at the same time

createMachine({
  schema: {
    context: createSchema<{ foo?: number }>(),
    event: createSchema<
      | { type: "X", bar?: number }
      | { type: "Y" }
      | { type: "Z" }
    >()
  }.
  context: {},
  initial: "a",
  states: {
    a: {
      on: {
        X: {
          target: "c",
          guard: (_, event): event is { type: "X", bar: number } =>
            event.bar !== undefined
        }
      }
    },
    b: { on: { Y: "c" } },
    c: {
      entry: (_, event) => {
        // event is { type: "X", bar: number } | { type: "Y" }
        //                       ^^^ (no "?")  
      }
    }
  }
})

Here txstate can narrow down the X event because of the guard provided at entry of c. Though what if one had to even write a type guard for context at the same time? There's no such thing as the following

gaurd:
  (context, event):
    & (context is { foo: number })
    & (event is { type: "X", bar: number }) =>
      context.foo !== undefined &&
      event.bar !== number

You simply can't write a type gaurd for two parameters. Your best bet is have two guards...

gaurd: [
  (context, _): context is { foo: number } =>
    context.foo !== undefined,
  (_, event): event is { type: "X", bar: number } =>
    event.bar !== number
]

If it were ({ context, event }) => x we wouldn't have this problem as we could have written...

(state: { context, event }):
    states is {
      context: { foo: number },
      event: { type: "X", bar: number }
    } =>
      context.foo !== undefined &&
      event.bar !== number

2. Can't narrow context by a type guard on event and vice versa

Let's say this was a legit thing...

gaurd:
  (context, event):
    & (context is { foo: number })
    & (event is { type: "X", bar: number }) =>
      context.foo !== undefined &&
      event.bar !== number

But that still isn't good enough because now even if txstate types the entry like...

entry: (...[context, event]:
  | [{ foo: number }, { type: "X", bar: number }]
  | [{ foo?: number }, { type: "Y" }]
) => unknown

The user's will have to use speard types to leverage them correctly

c: {
  entry: (...state) => {
    if (state[1].type === "X") {
      // foo is defined here as state got narrowed down to
      // [{ foo: number }, { type: "X", bar: number }]
      state[0].foo.toFixed();
    }
  }
}

The moment the users use parameters the types are less accurate and we can no longer leverage them

c: {
  entry: (context, event) => {
    // context is { foo: number } | { foo?: number }
    // event is { type: "X", bar: number } | { type: "Y" }
    if (event.type === "X") {
      context.foo.toFixed();
      // error: foo maybe be undefined
    }
  }
}

But if it were ({ context, event }) => x the type would be the following...

entry: (state:
  | { context: { foo: number }
    , event: { type: "X", bar: number }
    }
  | { context: { foo?: number }
    , event: { type: "Y" }
    }
) => unknown

And now it would look more readable as we wouldn't have to access via "0" and "1".

c: {
  entry: state => {
    if (state.event.type === "X") {
      // foo is defined here as state got narrowed down to
      // { context: { foo: number }
      // , event: { type: "X", bar: number }
      // }
      state.context.foo.toFixed();
    }
  }
}

Though of course destructuring context and event also ends up with the same problem as parameters...

c: {
  entry: ({ context, event }) => {
    // context is { foo: number } | { foo?: number }
    // event is { type: "X", bar: number } | { type: "Y" }
    if (event.type === "X") {
      context.foo.toFixed();
      // error: foo maybe be undefined
    }
  }
}

Notice I call it "principally incorrect". That's because these two problems are consequential of a much deeper error. The error is - making context and event two different parameters of a fucntion, is making context and event two different categories instead of two different properties of the same category ie the machine state. Context and event exist in pair at different instants of the machine across the time. And no wonder the api too reflects that context and event are indeed properties of the machine state.

Now of course David is not to be blamed because he wouldn't have thought such minor difference would mean so many things and no way in the fuck he would have thought one day a guy named Devansh will leverage types to such an extent and yell at him "But bro context and event arent't supposed to be two different parameters !!11!!!1" xD

I would want suggest to make this breaking change because

It's not too much of a change.
A codemod that takes (ctx, e) and makes it ({ context: ctx, event: e }) would suffice.

A compatibility layer to facilitate migration can be provided in many ways..
a. different module - xstate/compat
b. flag - { parameterizedContextEvent: true }
c. a wrapper function -

const xF =
  <S extends { context: C, event: E }, C, E, R>(
    f: ( c: C, e: E) => R
  ) =>
    (state: S) =>
      f(state.context, state.event)

The reward seems to be high in comparison to the cost.

All said and done, no pressure as y'all are wiser than me when it comes to handing such a huge user base and breaking changes and everything that comes with it. But do consider this change!

Edit -
I realised it may look as if the second problem would only occur if the user uses type gaurds, no. I just continued with same example, though we'd be always having pairs of context and event. For example for let's say node x gets entered from three nodes a, b & c with events P, Q & R respectively. Then the context for the entry action of x would be according to the typestates. Meaning the entry type would look something like...

entry: (...[context, event]:
  | [ContextWhenA, EventP]
  | [ContextWhenB, EventQ]
  | [ContextWhenC, EventR]
) => unknown

Guards have the ability to narrow down context even further, though we'd always have something like above even if there are no guards involved. So the problem 2 has nothing to do with guards per se.

Edit 2 -
Needless to say I'm talking about all things that have this function signature, they all will face problem 2, not just entry actions.

Edit 3 -
Okay okay anti-climatic but realized TypeScript doesn't support inferring type gaurds more than one property deep so the snippets won't work though that doesn't discount the critic because it's just a matter of language feature (that we might have in future) and one can still have an abstraction like this of their own.

0 replies

devanshj · 2021-07-12T01:12:37Z

devanshj
Jul 12, 2021

I think it's worth maintaining a list of issues that users actually came across that can be solved by txstate, so we'd know how of much of real world impact we're going to have. I think it'd be a good metric. I'm not labelling them just a bunch of links. Feel free to mention me in a problem to know if txstate can solve it so we can add it to this list.

0 replies

davidkpiano · 2021-07-12T12:50:50Z

davidkpiano
Jul 12, 2021
Maintainer Author

@devanshj Have you seen the new model.createMachine(...) method?

const userModel = createModel({
  name: 'David'
});

const userMachine = userModel.createMachine({
  // no need to specify initial `context`!

  entry: (context, event) => {
    // context and event are fully typed from model
  }
});

This might help with type inference since in that createMachine, we can guarantee that we can have the types for context, events, and more in the future, so that's a solved problem.

14 replies

devanshj Jul 22, 2021

Yeah this is a concern that txstate hasn't dealt with yet. Firstly to have the types in the mixin could use createMachine itself and then spread it via machine.config but I'm yet to look if spreading doesn't result in bad type behaviour in the machine it's being spread in. As I said this is not something I've looked into so I'm only roughly speaking on macro level, I know on micro level there must be things to deal with. I'll concretely comment on it hopefully soon!

geekox86 Jul 22, 2021

Thank you @devanshj. Ideally, the JS/TS language should provide concepts, constructs, and design patterns to allow for multiple inheritance, traits, and/or composition that enable strong typing. Namespacing with manual merging is not ideal. I am not sure if there are better approaches?

devanshj Jul 22, 2021

I know what you're saying but generally speaking I disagree with the notion of language providing high-level ways of abstraction, you see I'm those fp types, an haskeller would agree with me :P

Though in context of state machines and xstate I'm really not the person who would be able to answer if there are better approaches. David might answer this better or better you could even start a new top level discussion on the shortcomings of the current approach (I think there already are along the same lines iirc). I'm not the person because as ironic as it is I have seriously never used xstate or have ever written a state machine xD (I'm here because I like typing challenges :P though it's philosophy surely changed the way I write things)

geekox86 Jul 22, 2021

Actually, I am impressed with your work to the point that I have downloaded your repo for studying purposes 👍
I will follow your advise to take this to another discussion, but I will be waiting for your comments and suggestions regarding strongly typing the config (definition) / options (implementation) approach. Thank you.

devanshj Jul 22, 2021

Actually, I am impressed with your work to the point that I have downloaded your repo for studying purposes 👍

Thanks a lot! Feel free to open issues asking specific questions, I'll answer them in my available bandwidth.

I will be waiting for your comments and suggestions regarding strongly typing the config (definition) / options (implementation) approach.

Sure thing, it's definitely a thing I'll have to address eventually if not now.

codingedgar · 2022-02-27T03:12:50Z

codingedgar
Feb 27, 2022

Let's discuss potential upcoming TypeScript improvements to XState v5 and how we might be able to implement them (cc. @devanshj):

Types for context, events, actions, guards, actors, delays should be able to be inferred from .schema

.initial property should autocomplete key from .states

Granular error if .initial property is not key from .states

States that are not .type: 'compound' (implicit or explicit) should not have a .states property

Actions, guards, actors, delays, etc. should be strongly typed throughout states + autocomplete

onDone should have its .data strongly typed for invoked promises

(todo: add more asks)

idk if this is up to date, but if so, I think the other point to add would be to know what's the context is inside actions/services (typestates but everywhere)

5 replies

Andarist Feb 27, 2022
Maintainer

Yeah, fully working typestates is the dream but I think they are out of scope for v5. It's just too complex to be put in the scope. The feature is also somewhat blocked by TS - since the control flow analysis can't refine the type of a "deep" property. OTOH we could try not to compute possible combinations for context+event pairs and we could just limit ourselves to operate on context alone - this doesn't make it in particularly easier to implement though 😅

codingedgar Mar 1, 2022

Oh, that's fine, hope TS makes it easier in the future.

If you don't mind me asking, why doesn't XState take an approach like Akka become? (besides what I guess "that's not statecharts"):

https://doc.akka.io/docs/akka/current/actors.html#become-unbecome

I see/use XState for what would basically be "a powerful description of Async IO Pattern Matching in JavaScript/TypeScript" the only missing piece is how to safely go from one state to the other in pairs of [State, Context], but idk if I keep wishing for this property because I'm seeing it the wrong way because that assurance doesn't exist on JavaScript either.

Is my understanding of statecharts deeply flawed or this is actually a technical limitation to a valid way of using statecharts? I assume is the former, because there's no way to safely specify the right context when going to another state, but I yet fail to feel comfortable not describing state machines as distinct [State, Context, Events], is there a place I can read more about this tradeoff to see why make it one way instead of another? I have a hard time feeling a Pattern Matching mechanism (typed or not) complete when you cannot assure the next state context shape too. I'm asking because probably with the right pattern/midset I can write better XState definitions instead of feeling short to express myself.

I also wonder if it is possible to maybe make something like this in a wrapping library that specializes in writing state machines based on state machines, I know we can merge state machines definitions (like code splitting states), but idk how to merge two fully typegen'd createMachine machines (besides actors).

I haven't fully tried much in this area because I feel it kinda defeats the purpose of statecharts, (combining flat states easy but nested/parallel hard), somehow I still have the idea it needs to be baked in, not only for TypeScript but for safety in general, no target without specifying witch which context you're transitioning too, like an F# Tagged Union.

davidkpiano Mar 1, 2022
Maintainer Author

@codingedgar XState doesn't take a "become" (pattern-matching) approach for two reasons:

The logic becomes split up between multiple functions. This isn't a bad thing, but in practice, and especially compared to what XState enables, this means that it becomes much more difficult/impossible to visualize the entire logic, much less statically analyze it, and furthermore, it can't be run in a serverless setting, because you can't easily rehydrate a become()-first behavior. For example, running XState in a serverless context is easier because there are no hot-swapped message handlers, there is only one message handler: the statechart that contains all of the possible behaviors when a message is received.
You can think of "state node matching" (which is what statecharts do) to be a more advanced, but incompatible form of pattern matching. You can have nested pattern matching, but ultimately, only one branch will be selected.

With statecharts, it's like pattern matching where multiple branches may be selected, and ultimately combined. This is very powerful, but also difficult to strongly type in a natural way. See this illustration, where green and orange represent two different scenarios where branches are chosen:

codingedgar Mar 1, 2022

Thanks a lot for your quick and visual response ✨

The logic becomes split up between multiple functions. This isn't a bad thing, but in practice, and especially compared to what XState enables, this means that it becomes much more difficult/impossible to visualize the entire logic, much less statically analyze it, and furthermore, it can't be run in a serverless setting, because you can't easily rehydrate a become()-first behavior. For example, running XState in a serverless context is easier because there are no hot-swapped message handlers, there is only one message handler: the statechart that contains all of the possible behaviors when a message is received.

Maybe I imagine it in my head as "inspired by Akka" but not so literal, I meant become is another property, similar to cond, where it forces the user to implement a map ContextA -> ContextB, this way we have certainty when in stateB, then we have ContextB, like implementing the narrowing explicitly.

const wizardMachine = createMachine({
  id: 'wizard',
  initial: 'open',
  states: {
    open: {
      initial: 'step1',
      states: {
        step1: {
          on: {
            NEXT: { target: 'step2', become: 'fromStep1toStep2' } // A -> B
          }
        },
        step2: {
          /* ... */
        },
        step3: {
          /* ... */
        }
      },
      on: {
        NEXT: { target: 'goodbye'}, // maybe no need of become because the target is final
        CLOSE: { target: 'closed', become: 'anywhereToGoodbye' } // but maybe we still want a context at a final stage, A | B | C -> D
      }
    },
    goodbye: {
      on: {
        CLOSE: { target: 'closed' } // maybe no need of become because the target is final
      }
    },
    closed: {
      type: 'final'
    }
  }
});

In my head, that is compatible in all cases, it is what I see every day, but implicitly. Hydration and other state transitions are still completely supported (sorry if I fail to see the conflict), it is no more or less than how cond is used today, become might even be A -> Option<B> where if none then the transition does not take place, otherwise is a successful transition, this is what is normally coded as cond + assign. (ok, maybe the Option: None | Some<T> is an extra type, A -> B | undefined would suffice) but with more guarantees when done together in an atomic expression.

If we want a more "clean" description of the machine, become does not event has to be written in the description, it could be required and verified at runtime as many other properties, and each transition has to have a become assigned to it (like, no empty on, or onError in strict more)

const wizardMachine = createMachine({
  id: 'wizard',
  initial: 'open',
  states: {
    open: {
      initial: 'step1',
      states: {
        step1: {
          on: {
            NEXT: { target: 'step2' }
          }
        },
        step2: {
          /* ... */
        },
        step3: {
          /* ... */
        }
      },
      on: {
        NEXT: { target: 'goodbye'}
        CLOSE: { target: 'closed' } 
      }
    },
    goodbye: {
      on: {
        CLOSE: { target: 'closed' }
      }
    },
    closed: {
      type: 'final'
    }
  }
}, {
 become: {
    fromStep1toStep2: (a: A): B => { }
  }
});

You can think of "state node matching" (which is what statecharts do) to be a more advanced, but incompatible form of pattern matching. You can have nested pattern matching, but ultimately, only one branch will be selected.

With statecharts, it's like pattern matching where multiple branches may be selected, and ultimately combined. This is very powerful, but also difficult to strongly type in a natural way. See this illustration, where green and orange represent two different scenarios where branches are chosen:

I see the point, thanks for the good visual representation.

yet in practice, we do discriminate the Context shape per State, even when we have parallel states, I see XState precisely as parallel-nested-pattern-matching today. We always have to have if statement in our actions, as 1 cond does not narrow types and 2 if the machine is in a certain state it is because it is sure of certain things.

Today we do this all the time by testing, and making sure the Context is not invalid in a certain Node, is like redux vs xstate, when in redux we do have finite-state all the time, but xstate expresses it better, we can also finally tight the knot with Node: [Context, Events] instead of Node: [Events], because we do have infinite state per Node.

Right now the only things we can define are the Events that get executed in a Node, can the Node have certain data? like invoke[0].done does, it is certain of that data, we have it, we shape it constantly, yet when pushed to the Context all assurance fly out of the window, as the next actions will have to verify again the data is there, data we put just right before entering that state, and only make sense within the state.

Maybe the issue is Context ownership, when the Context is shared between multiple parallel states, one might delete something the other assigned (which creates a bug in logic, because that means we are in a state we shouldn't be anymore anyways), maybe we should be able to express per-node Context, and global Context, then when we can only see Node Context inside that Node actions, as we see today with narrowed events.

All of this is for JavaScript also, the TypeScript issue, in my head, has nothing to do with how the transitions are missing the Context narrowing part.

codingedgar Mar 1, 2022

Maybe this is a bit extra, but we could see Context as a graph also, just as we see Nodes inside actions.

actions:[
 (globalContext, event, meta) => {
     const thisNodeContext = meta.node.context;
     const parentContext = meta.parent.context;
  }
]

Is there any way to toy with this without making a fork? does XState has an extension mechanism?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

XState v5 TypeScript improvements #2323

{{title}}

Replies: 6 comments 19 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

XState v5 TypeScript improvements #2323

davidkpiano Jun 21, 2021 Maintainer

Replies: 6 comments · 19 replies

txstate feature list (incomplete)

Better schema

Critic: Why it should have been ({ context, event }) => x instead of (context, event) => x and is it worth fixing it?

Problems with (context, event) => x

1. Can't write a type gaurd for both context and event at the same time

2. Can't narrow context by a type guard on event and vice versa

davidkpiano Jul 12, 2021 Maintainer Author

Andarist Feb 27, 2022 Maintainer

davidkpiano Mar 1, 2022 Maintainer Author

davidkpiano
Jun 21, 2021
Maintainer

Replies: 6 comments 19 replies

Better `schema`

Critic: Why it should have been `({ context, event }) => x` instead of `(context, event) => x` and is it worth fixing it?

Problems with `(context, event) => x`

davidkpiano
Jul 12, 2021
Maintainer Author

Andarist Feb 27, 2022
Maintainer

davidkpiano Mar 1, 2022
Maintainer Author