Typescript problem: can't use actions inside always

[DirkWolthuis]

Hi all,

With TS version 4.0.3 I get a Typescript error that I can't place.

 starting: {
        always: [
          { target: "loadingGenerator", cond: "checkId" },
          {
            target: "editGenerator",
            actions: assign({
              generator: () => new Generator(),
            }),
          },
        ],
      },

The actions object gives the following typescript error: Type 'AssignAction<{ generator: Generator; }, GeneratorEvents>' is not assignable to type 'string | ActionObject<GeneratorContext, GeneratorEvents> | ActionFunction<GeneratorContext, GeneratorEvents> | Action<...>[] | undefined'. Type 'AssignAction<{ generator: Generator; }, GeneratorEvents>' is not assignable to type 'string'.ts(2322)

The context is of type generator: Generator, so I don't think that is a problem.

[DirkWolthuis]

And the code works just fine :)

[davidkpiano]

Have you tried assign<YourContext>({ ... })?

[DirkWolthuis]

 Still the same problem

[davidkpiano]

✏️ Please create a CodeSandbox (XState TypeScript template) reproduction of this. Thanks!

[DirkWolthuis]

https://codesandbox.io/s/xstate-typeproblem-jndq5?file=/src/index.ts

Same code and typescript version but no error?

[Andarist]

How can you be sure that this is using the same TS version as you do? I can't find the TS version to be specified anywhere in this codesandbox.

[DirkWolthuis]

In the right bottom corner. Same place as VSC

[Andarist]

Ah, right - I could have sworn that I've looked there because I've remembered that it was working like VScode but didn't spot it in a rush 🤷‍♂️

So if everything works in the sandbox then the problem might be related to a configuration or some other project exclusive circumstances. Could you try to prepare a repository with the issue reproduced?

[DirkWolthuis]

My repo with the problem is public (https://gitlab.com/DirkWolthuis/dutch-dnd-tables). My TS version of VSC is set to 4.0.3 with is also the TS version in the project (located in packages/front). Sorry spending your time with this :(

[Andarist]

Once you provide any generic you have to provide them all - so in this case you can solve this by adding the second one, so it should be:

actions: assign<GeneratorContext, GeneratorEvents>(/* ... */)

Ideally, this would work without any generics provided explicitly though. It's a known problem with our typings right now - I'm thinking actively how to fix this but it has proven to be hard. Our work on xstate-codegen should aim to solve this - but, of course, this will require an additional setup etc. The benefits will outweigh the costs though 🤞

The problem arises because TS doesn't try to match the return type to the context type, it's somehow related to the return type being a Partial of our TContext generic. You can trick this by writing this:

actions: assign((ctx) => {
  return {
    ...ctx,
    generator: {
      name: "",
      shared: true,
      description: "",
      language: "nl",
      user_id: 1,
    },
  }
})

[DirkWolthuis]

cool thanks that works!

…

[davidkpiano]

Reference to working answer:

Once you provide any generic you have to provide them all - so in this case you can solve this by adding the second one, so it should be:

actions: assign<GeneratorContext, GeneratorEvents>(/* ... */)

Ideally, this would work without any generics provided explicitly though. It's a known problem with our typings right now - I'm thinking actively how to fix this but it has proven to be hard. Our work on xstate-codegen should aim to solve this - but, of course, this will require an additional setup etc. The benefits will outweigh the costs though 🤞

The problem arises because TS doesn't try to match the return type to the context type, it's somehow related to the return type being a Partial of our TContext generic. You can trick this by writing this:

actions: assign((ctx) => {
  return {
    ...ctx,
    generator: {
      name: "",
      shared: true,
      description: "",
      language: "nl",
      user_id: 1,
    },
  }
})

#1480 (reply in thread)