When to call makeAutoObservable?

[williamrjribeiro]

Hello!
I'm a bit confused regarding something very basic regarding makeAutoObservable and makeObservable. The documentation shows that it is usually the 1st thing called in the class constructor.

But in my setup doing so does not work as expected. My app setup was bootstrapped with create-react-app:

"dependencies": {
    "mobx": "^6.0.1",
    "mobx-react-lite": "^3.0.1",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
    "react-scripts": "4.0.0",
     ...
}

Here's a codesandbox with the issue reproduced.

Since this is the first time here, and new to Mobx, I'm not sure if this is an issue or if I'm just overlooking something.
Any help appreciated.
Thanks! 🙇

[urugator]

makeAutoObservable/makeObservable makes observable only existing properties:

class Doubler {  
  constructor(val) {    
    this.value = val || 0;
    makeAutoObservable(this);    
  }
}

You can use property initializer, but you have to assign some initial value:

class Doubler {  
  value = 0
  constructor(val) {    
    makeAutoObservable(this);    
  }
}

Because:

class Doubler {  
  value;
  constructor(val) {    
    console.log(this.hasOwnProperty('value')) // false
    makeAutoObservable(this);   
  }
}

[mweststrate]

Because:

Note that this is only a problem when using non spec compliant (legacy) transpilation. If TypeScript / Babel is configured correctly, declaring a field through value; will be no problem for makeAutoObservable. It might be that CRA uses legacy transpilation ootb. For details see https://mobx.js.org/installation.html#use-spec-compliant-transpilation-for-class-properties

[williamrjribeiro]

Oh wow, initializing the property did the trick! value = 0; 🤘

Thanks for the quick and thorough answers.

Maybe the example code in the documentation could be updated with initialized class properties so that no one else wastes much time as I did trying to figure out this issue. Or call makeObservable last in the constructor. Just suggestion.

Cheers! 👍

[phoenixeliot]

@mweststrate

I'm finding that even with the supposedly correct configuration of TypeScript ("useDefineForClassFields": true in .tsconfig) I still must initialize my class fields (not just declare their type), or else they don't get observed by makeAutoObservable. Any idea why this is?

If I put in the suggested canary error-throwing code, it indeed throws the error about the transpiler being misconfigured.

This is my entire .tsconfig; most of the values are from the default next.js config, and target is es6 to make jest easier to deal with. I also tried a target of esnext and es5 with the same results.

{
  "compilerOptions": {
    "target": "es6",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    // "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "downlevelIteration": true,
    "strict": false,
    "useDefineForClassFields": true // required for MobX
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

Here is a reference repo with this problem, if it helps: phoenixeliot/line-puzzle@3eb1a41

Currently this throws the explicit check error. If you disable that, and if you remove the initial value for Cell.color, the "solve choiceless moves" button stops working.

[phoenixeliot]

Looking at the compiled code, it looks like Next.js might be ignoring tsconfig for the sake of actual compilation. I'll see if I can figure out how to change next.js's compilation behavior here and suggest something we could add to the docs for this.

EDIT: Bah, looks like it just needs the babel config. Perhaps we could add a quick note to the documentation noting that for Next.js, the user must add a babel config instead of modifying the .tsconfig, even if they're using typescript?

This is the correct config to use for .babelrc with next.js:

{
  "presets": ["next/babel"],
  "plugins": [["@babel/plugin-proposal-class-properties", { "loose": false }]],
  // Babel >= 7.13.0 (https://babeljs.io/docs/en/assumptions)
  "assumptions": {
    "setPublicClassFields": false
  }
}