ES2015 & 2016 Features meta-issue #560

Open
samwgoldman opened this Issue Jun 24, 2015 · 36 comments

Projects

None yet
@samwgoldman
Member
samwgoldman commented Jun 24, 2015 edited

Feel free to open an issue for any unchecked feature that doesn't already have one, but please try to keep discussion in a single issue if possible. Use cases (and test cases) are very welcome!

To report a bug with a completed feature, please open a new issue for the bug.

ES2015

  • let/const declarations (#784)
  • Regular expression u flag (#2510)
  • Regular expression y flag
  • Binary literals (#566)
  • New octal literals (#566)
  • Arrow functions
  • Default parameters (mostly supported, except using this: #1234)
  • Rest parameters
  • Spread operator
  • super references
  • Classes
  • for-of loops
  • Generators (#534)
  • Object literal property shorthand
  • Object literal method shorthand
  • Object literal computed properties (#252)
  • Template strings
  • Tagged templates
  • Tagged template fn strings param has a raw prop
  • Tagged template fn strings and raw arrays are frozen
  • Destructuring
  • Default values in destructuring (#183)
  • Unicode code point escapes
  • Allow duplicate object literal properties (except proto)
  • Modules
  • new.target (#1152)
  • Symbols (#810, #1015)
  • export Foo from 'foo' (#2403)

Non-standard proposals

  • async/await (stage 3)
  • object spread (stage 2)
  • async iterators (stage 3) (#1824)
  • class property initializers (stage 1) (#850)
  • class decorators (stage 1)
  • method decorators (stage 1)
  • function bind operator (stage 0) (#1545)
  • do expressions (stage 0) (#2523)
@mroch
Contributor
mroch commented Jun 25, 2015

this is super useful!

there are probably a bunch of new APIs that we need to add, too. for example, I just noticed that we don't have String.prototype.codePointAt (part of new unicode stuff)

@nmn
Contributor
nmn commented Jun 29, 2015

Perhaps, add an ES7 section and mark async-await as done.

(BTW, I find it surprising that async-await is done before generators!)

@Globegitter

It seems there is an issue with ES6 Class support. I am using atom/nuclide IDE and having the following code:

export default class Resource {
  constructor(req:string) {
    this.req = req * 2;
  }
}

assignment of property req Property req not found in Resource even though I am defining it here in the constructor.

@gabelevi
Contributor

@Globegitter, Flow wants you to declare class properties like so:

export default class Resource {
  req: number;
  constructor(req: number) {
    this.req = req * 2;
  }
}

Why do we require this? Well, if we don't make people declare properties then we can't detect things like

function getReq(resource: Resource): number {
  return resource.rep;
}

We do realize this is a little bit more work for the developer, but we're hoping the benefits outweigh the pain.

@Globegitter

Aahh, I see, thanks @gabelevi For know I mostly want to use flow for its type inference with /* @flow weak */. The issue here is that I can not just put req; res; at the top, it does throw an 'Unexpected token;` issue.

Generally I do think this is an acceptable extra-effort, but why can flow not just get the information from the constructor itself? Is it that much more complex to see what this.req is assigned to and then look up the type in the constructor's parameter list?

As a side note kind of fitting to this, it would be great to see property initialiser support as mentioned here: http://babeljs.io/blog/2015/06/07/react-on-es6-plus/

@gabelevi
Contributor

I think at the moment that Flow requires type annotations for the class member properties you declare. So

req: any; res: any;

should work. I did recently change the parsing of that (7e5b2a9) in preparation for class property initializers. We absolutely are planning support for class property initializers. They solve so many problems! The one I hate the most is how you have to do

class Foo {
  constructor() {
    this.myCallBack = this.myCallBack.bind(this);
  }
  myCallBack() { ... }
}

but with class property initializers you can do

class Foo {
  myCallBack = () => { ... }
}
@Globegitter

Thanks for the quick response that all sounds good :) And yep it really does solve a lot of issues.

@samwgoldman
Member

Generally I do think this is an acceptable extra-effort, but why can flow not just get the information from the constructor itself? Is it that much more complex to see what this.req is assigned to and then look up the type in the constructor's parameter list?

@Globegitter, good insight! Actually, flow used to do this, but the functionality was removed. I'm not sure about the details surrounding this, but there is some explanation in a comment in the source code.

Unfortunately, this change was from the days of "sync to upstream" so the diff is big and it's hard to see the implications in terms of the code changes themselves.

@oztune
oztune commented Jul 28, 2015

image

^ What happened with let support?

I think it'd help if this was taken care of if only because at a glance it makes the whole project seem to be behind. For example it's being used as a con on this list, which happens to be a top result for googling "flow vs TypeScript"

image
http://www.reddit.com/r/javascript/comments/39cere/typescript_vs_flow_results_from_our_investigation/

Also in this comment:
image
http://www.reddit.com/r/javascript/comments/39cere/typescript_vs_flow_results_from_our_investigation/ct6xagb

Flow looks really promising, keep up the great work!

@samwgoldman
Member

What happened with let support?

We're actively working on it. Please be patient.

@nmn
Contributor
nmn commented Jul 28, 2015

@oztune by all means use my fork in the mean time: github.com/nmn/flow

  • Up to date with flow itself
  • Let/const support added by making flow treat them like var. (if you use Babel, the block scoping and const checking is already done for you)
@gregwebs

classes are checked, but class property initializers are not supported: can we have a check box for that? Making it hard for me to swallow ES6 classes right now.

An alternative approach to much of this work is to leverage babel more

@samwgoldman samwgoldman changed the title from ES6 Features meta-issue to ES2015 Features meta-issue Aug 29, 2015
@samwgoldman
Member

@gregwebs class property initializers are not ES6/ES2015, but it's definitely on our radar. I think, instead of creating a separate meta issue for ES2016 features, we should just track that here. I'll make the necessary changes.

@samwgoldman samwgoldman changed the title from ES2015 Features meta-issue to ES2015 & 2016 Features meta-issue Aug 29, 2015
@gregwebs

Ah, in that case I will take any hack I can get. Seems to work to put this in the constructor:

      // fix broken es6 classes
      _.each(Object.getOwnPropertyNames( Object.getPrototypeOf(this) ), prop => {
        this[prop] = this[prop].bind(this)
      })
@Gozala
Contributor
Gozala commented Sep 11, 2015

@samwgoldman I think it would make sense to update #431 to #784 given that's where the ongoing work is now.

@samwgoldman
Member

@Gozala You're right! Thanks & done.

@cesarandreu
Contributor

I'd vote for adding export extensions to the ES2016 list. (Not sure if they're supported?)

@samwgoldman
Member

Is there an maintained list of the various proposals, along with the stage? Official would be ideal, but anything would help.

@cesarandreu
Contributor

@samwgoldman there's a list of the ones that are available in babel.

@tsing
Contributor
tsing commented Sep 17, 2015

@samwgoldman I thinks the Reflect should be added to the list of ES2015

@Gozala
Contributor
Gozala commented Sep 17, 2015

I think #810 should be on the list as well

@bolinfest
Contributor

@samwgoldman I just filed #850 for ES7 property initializers, so could you please update this issue with that?

@RavenHursT

What about ES6 Getters and Setters? Currently Flow doesn't support the syntax, correct?

http://javascriptplayground.com/blog/2013/12/es5-getters-setters/

@hzoo
Contributor
hzoo commented Oct 16, 2015

@RavenHursT you can add unsafe.enable_getters_and_setters=true under [options] in your flowconfig

@RavenHursT

@hzoo so looks like back in 0.14 they added what you're suggesting.. what does the unsafe denote? Is this something we can use now in 0.16 and it'll work?

https://github.com/facebook/flow/releases/tag/v0.14.0

@samwgoldman
Member

@RavenHursT It's unsafe because a setter/getter might have a side-effect that causes a program to have a runtime error, but Flow won't catch it.

@RavenHursT

@samwgoldman Got it. Thanks! ๐Ÿ‘

@tsing
Contributor
tsing commented Oct 21, 2015

@samwgoldman Could you add ES7 function bind syntax to the list ?
It is useful when use React ES6 classes

https://github.com/zenparsing/es-function-bind

@samwgoldman
Member

@tsing I'm not sure we should even track stage 0 (strawman) proposals. I'd like to see that proposal make a bit more standardization progress first.

@jrajav
Contributor
jrajav commented Feb 24, 2016

Is there already an issue for documentation somewhere? I don't know if it's supposed to be yet, but how to annotate arrow functions doesn't seem to be documented in http://flowtype.org/docs/functions.html.

@marudor
Member
marudor commented Apr 17, 2016

List is outdated:
Class Decorator are fixed with #1638
Regexp u and y flags with #1177

@willclarktech

+1 for function bind operator

@anaibol
anaibol commented Jun 5, 2016

+1!

@rosskevin

ES2015/2016 classes without semicolons break the parser and provide incorrect errors. See #1908 with test repo included.

@ghost Unknown added a commit that referenced this issue Jul 18, 2016
@jrajav jrajav + Facebook Github Bot 5 Update 01-functions.md with ES2015 function features [Ref #560]
Summary:
Add information about annotating ES2015 default values and arrow functions (based on current behavior) to the Functions docs.
Closes #2075

Reviewed By: bhosmer

Differential Revision: D3572098

Pulled By: avikchaudhuri

fbshipit-source-id: 241341efed5a4fcc72e8ddb741ec8e67793452a5
9ca4c3e
@rpominov
rpominov commented Sep 17, 2016 edited

Couldn't find class literal properties in the list. For example:

class Id<T> {
  _x: T;
  constructor(x: T) {
    this._x = x
  }
  static 'fantasy-land/of'<T>(x: T): Id<T> {
    return new Id(x)
  }
}

Flow yields:

static 'fantasy-land/of'<T>(x: T): Id<T> {
       ^ literal properties not yet supported

Is this on agenda? We need this for Fantasy Land.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment