TypeScript: Action-annotated method is undefined

[jbreckmckye]

I'm having a strange issue with the MobX annotations, where an @action method doesn't exist on the resultant object. I'm not sure if the issue is with MobX, TypeScript / TSC, Parcel, or something else.

If my class source is the following TypeScript:

    export class Car {
        @observable
        public wheels: number = 4;
    
        @action
        public selfDestruct() {
            this.wheels = 0;
        }
    }

And I invoke the method as follows:

    const car = new Car();
    car.selfDestruct();

I get an error:

Uncaught TypeError: car.selfDestruct is not a function

Evaluating car.selfDestruct in the console returns undefined.

However, if I use the action function all seems fine:

    export class Car {
        @observable
        public wheels: number = 4;
    
        public selfDestruct = action(
            () => this.wheels = 0
        );
    }
    
    const car = new Car();
    
    car.selfDestruct(); // works fine

Why can't I use the @action annotation?

For reference, I am using MobX 5.5.2 with TypeScript 3.1.1. The compilation is being handled by ParcelJS 1.10.1. The target is an Electron app.

---

if it helps, here's my tsconfig:

{
    "compilerOptions": {
        // Compiled module type. Node uses CommonJS.
        "module": "commonjs",

        // Target language level
        "target": "es2016",

        // Explodes if type cannot be inferred
        "noImplicitAny": true,

        // Don't assume any type may also be a null
        "strictNullChecks": true,

        // Follow module paths like a Node app
        "moduleResolution": "node",

        // Where to output compiled code
        "outDir": "dist",

        // Allow ES2015-style default imports from files with no explicit export-default
        "allowSyntheticDefaultImports": true,
        "esModuleInterop": true,

        "experimentalDecorators": true,

        // Transpile JSX files to React-Hyperscript
        "jsx": "react"
    },
    "exclude": ["node_modules"]
}

[chutchinson]

I fixed this by switching the compilation target to "es5". Haven't looked into the underlying problem.

[jbreckmckye]

If I target ES5, won't I lose the benefits of proxies?

[mweststrate]

@jbreckmckye no, target just specifies which language features are used, not which standard library is used

[jbreckmckye]

It's still not working for me unfortunately.

Also - I can't get class members decorated with @observable to function either.

For example, if I instantiate the class -

class Foo {
     @observable
     public myNumber = 5;
}

foo = new Foo();

When I inspect the object, the myNumber property is not an observable, but a raw primitive:

This is using the TSC options target: es5 and lib: ['dom', 'es2015']

[jbreckmckye]

Oh - one thing, I am using Parcel's --target electron flag, which (as I understand it) means the bundle won't contain any of its package.json dependencies - they'll get imported at runtime instead. Could this affect anything?

[mweststrate]

Are you (or parcel) using babel? If so, what is it's configuration? It seems like decorators are not applied at all? Op di 6 nov. 2018 om 16:55 schreef Jimmy Breck-McKye < notifications@github.com>:

…

Oh - one thing, I am using Parcel's --target electron flag, which (as I understand it) means the bundle won't contain any of its dependencies - they'll get imported at runtime instead. Could this affect anything? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1790 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhLDwnf0CciWuhfXMEHW13GdF_wFIks5usbD2gaJpZM4X8eEf> .

[jbreckmckye]

Hi Michael - thanks for being so patient.

So - this is going to sound rather strange, but I think I've found the issue, and it's something to do with my tsconfig setup, with multiple config files.

---

I originally had three tsconfig files - one root, one for the main thread and one for the renderer, as below:

main tsconfig

{
    "compilerOptions": {
        // Compiled module type. Node uses CommonJS.
        "module": "commonjs",

        // Target language level
        "target": "es2016",

        // Explodes if type cannot be inferred
        "noImplicitAny": true,

        // Don't assume any type may also be a null
        "strictNullChecks": true,

        // Follow module paths like a Node app
        "moduleResolution": "node",

        // Where to output compiled code
        "outDir": "dist",

        // Allow ES2015-style default imports from files with no explicit export-default
        "allowSyntheticDefaultImports": true,
        "esModuleInterop": true
    },
    "exclude": ["node_modules"]
}

renderer tsconfig:

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "jsx": "react",
    "experimentalDecorators": true
  },
  "include": ["./**/*", "../types/**/*"]
}

The TypeScript documentation suggests that this should work just fine; all the compilerOptions will be merged for each compile target.

This would output class code that looked a little like this:

function () {
  function SomeClass(imagery, record) {
      ...
  }

  Project.prototype.doAThing = function () {
    console.log('this is an action');
  };
  __decorate([mobx_1.action], Project.prototype, "doAThing");

  return Project;
}();

Calling new Someclass().doAThing with this setup results in an undefined is not a function.

When I join the tsconfigs, however, things look subtly different. The proper class syntax is used and the __decorate function is called in a different way:

unified tsconfig

{
    "compilerOptions": {
        // Compiled module type. Node uses CommonJS.
        "module": "commonjs",

        // Target language level
        "target": "es2016",

        // Explodes if type cannot be inferred
        "noImplicitAny": true,

        // Don't assume any type may also be a null
        "strictNullChecks": true,

        // Follow module paths like a Node app
        "moduleResolution": "node",

        // Where to output compiled code
        "outDir": "dist",

        // Allow ES2015-style default imports from files with no explicit export-default
        "allowSyntheticDefaultImports": true,
        "esModuleInterop": true,

        "experimentalDecorators": true,

        // Transpile JSX files to React-Hyperscript
        "jsx": "react"
    },
    "include": [
        "./src/**/*"
    ],
    "exclude": ["node_modules"]
}

Generated code:

class Project {
  constructor(imagery, record) {...}

  doAThing() {
    console.log('this is an action');
  }
}
__decorate([mobx_1.action], Project.prototype, "doAThing", null);

Now, both @observable and @action annotations seem to work just fine.

---

It's not clear to me exactly why my previous setup was mangling the compile output. Either the compilerOptions aren't really being merged properly or something strange is happening under the covers of tsc.

In either case, it seems I solve the issue fairly easily by using a single tsconfig.json file. This may also solve some IDE problems I'm having.

I'm not sure if there's a clear takeaway or explanation as to what can go wrong with multiple tsconfigs, but at least I now know they have some pitfalls. Thanks for your patience on this.

[jonlambert]

I'm experiencing this issue too. I'm using MobX with TypeScript and Next.js. @action or @observable decorated attributes are all initially undefined.

import { observable } from 'mobx';

class UserStore {
  @observable name = "Jon";
}

const store = new UserStore();

console.log(store.name); // undefined

Unfortunately changing the target to es5 doesn't help, and having to unify the tsconfig.json file seems like an unusual solution, especially as I only have one. Does anybody know why this might be happening?

[mweststrate]

Sounds like a bug that could be filed at TypeScript? Op za 8 dec. 2018 om 11:10 schreef Jon Lambert <notifications@github.com>:

…

I'm experiencing this issue in my project too. I'm using MobX with Next.js, and @action or @observable decorated attributes are undefined. Having to unify the tsconfig.json file seems like an unusual solution, especially as I only have one. Does anybody have any idea why this might be happening? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1790 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhFc6MyyPXeZ8a4ZHMW_DzktJRHmyks5u24_4gaJpZM4X8eEf> .

[jonlambert]

For those finding this issue later I managed to solve it by ensuring @babel/plugin-proposal-decorators is the first plugin in the list.

{
  "presets": ["next/babel", "@zeit/next-typescript/babel"],
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "legacy": true }],
    "transform-class-properties",
  ]
}

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or questions.