You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Flow is (mostly) smart about this already without annotations. I'm not clear what this new bind syntax is (do you have a link to a spec?), but I imagine flow will support it the same way that flow currently supports bind, call, and apply.
/* @flow */functionhead(count){returnthis.slice(0,count);}head.bind([])// OKhead.bind(1)// bad
I'm not clear what this new bind syntax is (do you have a link to a spec?)
Ah, sorry, forgot the link, fixed.
Flow is (mostly) smart about this already without annotations
Yes, but it would be nice to be able to annotate this instead, for documentational purposes (easier to understand at a glance and also allows for better error messages, as well as documentation generation), but also for standalone definitions.
Agree that we should support this to be annotated as a parameter. This requires some parser work too, btw, since this is not a valid identifier everywhere.
We need this whenever methods are exported, by the way. It's true Flow is good in inferring this types, but it sucks that this information is lost across modules.
Related: constructor functions can be annotated as of 618186a
Reacted by Joe Grund, Nicolas Jakob, Roma P., chocolateboy, Faris Masad, M. Walker Wells, Moritz Mahringer and andretshurotshka
The problem is that this inside the addEventListener callback refers to the XMLHttpRequest object (I believe) and not the RemoteFile class. The latter has a url property but not a status property, whereas the former has status but not url. Clearly this code isn't right!
Flow doesn't complain, though. It thinks this has type any in the event listener.
Where possible, the DOM declarations should indicate the type of this in callbacks to prevent this sort of mistake.
For example, Google's Closure Compiler provides an @this annotation. You can see an example of this in action in the declaration for Array.prototype.find.
Just for reference, TS 2.0 landed with this feature last month. It special-cases the first parameter if its name is this. I like that, reminds me of Python.
functionf(this: void){// make sure `this` is unusable in this standalone function}interfaceUIElement{addClickListener(onclick: (this: void,e: Event)=>void): void;}
Yeah, the callback literally does "receive" this object as a parameter. That's how it works for all functions. It just happens that there are different rules for how you pass the value of this, it doesn't appear in the arguments array, and there's a different default value in non-strict mode. Otherwise it's basically just another argument.
Makes sense to me. If babel-plugin-flow-strip-types stripped the entire first parameter when its name is this, it could work. Will likely require special-casing in ESLint etc.
Reacted by Esa-Matti Suuronen, Thorsten Lünborg, Desmond Brand, Greg Thornton, Frizi, Katja Lutz, chocolateboy, ivan, Michael Bøcker-Larsen and Moritz Mahringer
It's for library declaration and use site completion. This is quite common for context injection.
functionaddListener<T: HTMLElement>(elem: T,func: (this: T)=>void){// implementation}addListener(htmlInputElement,function(){this.value// should have this completion})
Another usage is in library like Vue/backbone.
Vue.extend({methods: {log(){this.instanceProperty// this is injected as Vue instance}}})
Without this annotation, it is impossible for library author to provide a good type declaration for automatic completion.
Reacted by kazuya kawaguchi, Eugene, Oscar N., Scott Bedard, Katja Lutz, Fernando H-T Goldáraz, chengchao, Nick Messing, tpines, Javier Chávarri and 9 more
Reacted by Scott Bedard, Herrington Darkholme, Katja Lutz, tpines, Masato Noguchi, Nick Messing, neotech-development, Sorin Iclanzan, Glebka Fokin, Loupasakis Kostas and 1 more
Reacted by Nick Messing, tpines, Andrei Glingeanu, Grzegorz Szeliga, neotech-development, sobolevn, Sorin Iclanzan, Loupasakis Kostas, Maxime Briziarelli, Louis Roman and 1 more
Activity
samwgoldman commentedon May 18, 2015
Flow is (mostly) smart about this already without annotations. I'm not clear what this new bind syntax is (do you have a link to a spec?), but I imagine flow will support it the same way that flow currently supports
bind,call, andapply.jussi-kalliokoski commentedon May 19, 2015
Ah, sorry, forgot the link, fixed.
Yes, but it would be nice to be able to annotate this instead, for documentational purposes (easier to understand at a glance and also allows for better error messages, as well as documentation generation), but also for standalone definitions.
jussi-kalliokoski commentedon Jun 9, 2015
Having thought about this a bit more, a simpler syntax would actually be to allow specifying
thisas a parameter, as so:avikchaudhuri commentedon Jun 19, 2015
Agree that we should support
thisto be annotated as a parameter. This requires some parser work too, btw, sincethisis not a valid identifier everywhere.We need this whenever methods are exported, by the way. It's true Flow is good in inferring
thistypes, but it sucks that this information is lost across modules.Related: constructor functions can be annotated as of 618186a
Artazor commentedon Aug 3, 2015
Hi guys! what about the following examples: microsoft/TypeScript#1985 (comment)
Are they too complex/ugly?
izaakschroeder commentedon Aug 7, 2015
+1
danvk commentedon Oct 22, 2015
Pulling in some material from #968: an example, and a link to how Google Closure does this.
There's an error (marked with
<---) in this snippet which Flow could potentially catch:The problem is that
thisinside theaddEventListenercallback refers to theXMLHttpRequestobject (I believe) and not theRemoteFileclass. The latter has aurlproperty but not astatusproperty, whereas the former hasstatusbut noturl. Clearly this code isn't right!Flow doesn't complain, though. It thinks
thishas typeanyin the event listener.Where possible, the DOM declarations should indicate the type of
thisin callbacks to prevent this sort of mistake.For example, Google's Closure Compiler provides an
@thisannotation. You can see an example of this in action in the declaration forArray.prototype.find.glortho commentedon Apr 18, 2016
In case you land here before this +1 functionality is added, and you need types just for the fn body, just do something like this:
STRML commentedon Aug 22, 2016
Just for reference, TS 2.0 landed with this feature last month. It special-cases the first parameter if its name is
this. I like that, reminds me of Python.An interesting note from the ticket when they were speccing it:
Makes sense to me. If
babel-plugin-flow-strip-typesstripped the entire first parameter when its name isthis, it could work. Will likely require special-casing in ESLint etc.nmn commentedon Mar 4, 2017
This already works in Flow:
Do we really need new syntax for this?
However there are some bugs with the approach as this totally bugs out:
HerringtonDarkholme commentedon Mar 4, 2017
@nmn Yes we do need.
It's for library declaration and use site completion. This is quite common for context injection.
Another usage is in library like Vue/backbone.
Without this annotation, it is impossible for library author to provide a good type declaration for automatic completion.
kazupon commentedon Mar 6, 2017
I hope this feature is provided 🙏
scottbedard commentedon Mar 21, 2017
+1 for this feature
iclanzan commentedon Feb 16, 2018
Has there been no progress on this yet?
dmnd commentedon Feb 16, 2018
@calebmer was looking for people to help implement it a while ago. I'm not sure if anyone started on it. I'd love to do it if I had more time.
KindWizzard commentedon Apr 5, 2018
Any updates on this? :)
akoppela commentedon Jul 30, 2018
@danvk It seems that you're using flow type version of
Q.Promise, is it? If so do you mind to share a link to flow typedQ.Pomiselibrary?danvk commentedon Jul 31, 2018
@akoppela https://github.com/hammerlab/pileup.js/blob/0182b225205e52e1489727004d69e84442eafb88/lib/q.js but take note that these are ~3 years old and there may be better ones available elsewhere.
Remove this annotation in function declarations
goodmind commentedon Jun 8, 2019
Hey! I tried to implement it at #7807
eilvelia commentedon Jul 19, 2019
Note that
thisconstraints in classes can be emulated via$Call^ flow try
^ flow try
^ flow try
^ flow try
iclanzan commentedon Jul 19, 2019
Wow, this is gold! Thank you @Bannerets!
dmnd commentedon Mar 10, 2020
Fixing
thiswas mentioned in the latest roadmap.STRML commentedon Jan 25, 2021
The
thisannotation was released in 0.139.To use, add this to flowconfig:
To use:
It is also usable at https://flow.org/try.
gkz commentedon Jun 11, 2021
https://medium.com/flow-type/sound-typing-for-this-in-flow-d62db2af969e