Why exactly do we need @babel/plugin-proposal-class-properties?

[amberv0]

Basically my question is in the title - why do we need @babel/plugin-proposal-class-properties in babel config?

I'm asking this because of this issue facebook/react-native#24421 , and removing the plugin doesn't seem to break anything in my app.

So I'm wondering what exactly is the need/use case for this babel plugin, and when can we omit this?

Thank you!

[kubk]

Hey, we provided a few examples here: #3216

Maybe we'll need to add this information to the documentation. There is also a JS one line script to check if your transpiler configured correctly, please check it: https://mobx.js.org/installation.html#use-spec-compliant-transpilation-for-class-properties

If it throws, your compiler needs tweaks described in the documentation.

[amberv0]

Thank you!
Somehow I didn't think about adding that oneliner to see if everything is ok. Adding some info in the documentation would be helpful indeed. As even with useDefineForClassFields set, we still need that babel plugin, and as it causes some issues sometimes, would be very nice to clearly see the answer to "why" - because otherwise fields that don't have initial values aren't picked up.

[amberv0]

maybe adding the option with "overrides" (cf another answer here) would also be nice

[urugator]

We would like to have react-native integration section, but I think it should be written by someone who uses and understands react-native. Afaik we don't have anyone on our team that uses react-native atm. There are various reports and solutions and it's not within our power to verify that these are valid and to keep these informations up to date. Frameworks use various setups and it's hard or impossible to provide a generic advice.

For the time being, I think we could just add that section to docs, with a notice that we are looking for a maintainer with react-redux experience and few tips/links to the issues. PR welcome.

As even with useDefineForClassFields set, we still need that babel plugin

It could be using a default config that you have to override. Or it could be using a compiler (eg. babel) that ignores (all/some) TS options. Or it could be using old compiler version with different defaults. Any of that could depend on some other framework specific configuration. Or it could be something completely different ...

why we need that babel plugin in the first place

The plugin makes your code behave as defined by ES standard. You may not even need it with newer babel/TS as it's enabled by default.
We rely on this standard behavior, some frameworks/libraries rely on different pre-standard behavior, therefore the issues.
The difference is in how public class fields are transpiled:

class X { 
  x;
  y = 0;
}

non-standard, loose:

class X { 
  constructor() {
    this.y = 0;
  }
}

standard, define:

class X { 
  constructor() {
    Object.defineProperty(this, "x")
    Object.defineProperty(this, "y", { value:  0 })
  }
}

[urugator]

Try #3100 (comment)

[amberv0]

Yes, I saw that fix (and luckily it works in my case), just wanted to understand why we need that babel plugin in the first place