facebook/create-react-app

Add support for decorators

kripod opened this issue · 17 comments

kripod commented

Note from maintainers

For people coming to this thread later—if you use MobX or a similar library, you don’t need decorators. They are just syntax sugar in this case.
Learn more: #214 (comment), #411 (comment).
Here is why we don’t include them: #411 (comment).

The lack of decorators is currently the only thing which makes me feel uncomfortable to use this project for a MobX-based frontend.

gaearon commented

We will add them when Babel supports them out of the box. The proposal is being updated (has it already been?) and we don't want users to suffer through a breakage caused by this.

IIRC MobX should work fine without decorators. It's just a little bit more verbose.

lacker commented

I would like decorators but I agree with @gaearon . It would be nice to have decorators in React Native too. Decorators are currently at "stage 1" in the ecmascript-standardization process, and it isn't until "stage 3" that all the syntax and semantics are complete, so I think it makes sense to wait. https://github.com/tc39/proposals

mxstbr commented

Since this seems like a consensus I'll close this. Thanks for kicking off the discussion @kripod!

kripod commented

I know that it may be against the philosophy of the project, but how about adding an opt-in .reactapp.json file which would allow advanced overrides to be made? The overrided configuration should be merged with the original, keeping the features specified by any of the configurations.

Example:

"overrides": {
  "babel": {
    "plugins": ["babel-plugin-transform-decorators-legacy"]
  },
  "eslint": {
    "extends": "airbnb"
  }
}
  • 👍5
gaearon commented

Sorry, we don't currently plan to support overrides like this. This makes it very hard for us to change the underlying settings and tools. You might have better luck with some of the alternatives listed in README!

  • 👍4
gaearon commented

For people coming to this thread later—if you use MobX or a similar library, you don’t need decorators. They are just syntax sugar in this case.

Learn more: #214 (comment), #411 (comment).

  • 👍1
  • 👎13
calebmer commented

Decorators are now not a legacy transform (see babel-plugin-transform-decorators) and is a part of babel-preset-stage-2. Now may decorators be added?

  • 👍25
wilzbach commented

@gaearon on a different issue you wrote

We’re happy to support decorators after the spec advances, and they are officially supported in Babel without the -legacy plugin.

Isn't this the case now? Is adding support for decorators now on your agenda?

gaearon commented

I'd be comfortable including them once they reach Stage 3. Treating them differently from Class Properties for reasons explained earlier: we dogfood Class Properties and will release a mod if they change.

  • 👍2
henryzp commented

@kripod , it support reactapp.json to overrides config now??

konradreiche commented

They are just syntax sugar in this case.

It's almost never just syntax sugar. Syntax can help to inherently reduce the complexity of a program. Reading a program, writing it, understanding it. All of these tasks can be improved in many ways with the right syntax not only reducing errors but also increasing pace.

  • 👍11
audiolion commented

@gaearon babel seems to now be off the -legacy plugin for 7.0 https://github.com/babel/babel/tree/7.0/packages/babel-plugin-transform-decorators

  • 👍6
  • 🎉2
canercandan commented

@gaearon might be the good time to have decorators now 👍

Timer commented

Hi @canercandan, the proposal is still stage-2.
We will probably not consider adding support until they've been in stage-3 for quite some time.

  • 👍2
anaibol commented

I don't want to eject..
landscape-1493048971-9146efea629aaa64fd5b42091842146c

There should be a way to configure CRA without ejecting, and without installing React Super Scripts or similar. We could configure Babel for example, even in an already created app. Maybe creating a config folder and setting the config folder as an env variable should leverage the CRA config.

  • 👍4
gaearon commented

For anyone reading this in the future, I would like to point out that the decorators spec has changed significantly. I'm really glad we made the decision to not support them at early stage, so users who didn't eject don't need to change their code.

I don't recommend anyone to rely on the legacy decorator transform (that is not part of CRA). See this thread for more info: https://twitter.com/dan_abramov/status/897491076537356288.

  • 👍4
  • 👎1
mweststrate commented

An update for MobX: from MobX 4 and onward, it will be a lot more simple to use MobX without decorator syntax. Enabling decorator syntax is no longer required to use decorators. Instead of writing

import { observable } from "mobx" 

class X {
  @observable y = 1
}

One can 'manually' apply the decorators using the decorate utility:

import { decorate, observable } from "mobx" 

class X {
  y = 1
}
decorate(X, { y: observable })

(Cross linking #214, #411 as those are closed, if a maintainer could link back to this comment that would be great :))

  • 👍4