Arrow functions in JavaScript - What, Why and How

O introducere rapidă în arrow functions:

Cea mai tare chestie la aceste funcții este că nu se mai schimbă contextul (this). În video se spune că asta e o chestie banală. :dash:

2 Likes

Cool stuff, pentru mai multe info https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions basically () => {}

Pare nitel criptica formularea, ma face sa-mi aduc aminte de un interviu pe care l-am dat acum cativa ani in Australia, era ceva de genul:

Explica diferenta intre [] + {} si {} + [] si de ce returneaza ce anume returneaza.

Impreuna cu alte giumbusliucuri de genul, mi s-a parut cel mai interesant interviu ever.

({} + []) === ([] + {}) si {} + [] === [] + {}

Sorry ca ti-am hijack-uit inca un thread @iamntz :stuck_out_tongue:

Mda, in schimb da un exemplu idiot ca sa scoata in evidenta ca a castigat 20 de caractere. Bandwidth-ul e salvat! In momentul in care incepi sa ai functii mai “consistente” diferenta devine ridicola.
Eu personal il consider un feature ne-necesar, poate nu pot eu sa ma obisnuiesc, dar nu mi se pare prea lizibila sintaxa asta. Iar treaba cu “this” nu era chiar asa o problema, dar, in fine…

Dincolo de caractere câștigate este vorba și de cod ceva mai lizibil. La o primă vedere este mai ambiguu, dar tind să cred că după o perioadă de acomodare nu mai reprezintă o problemă.

var that = this :smiley:

Mi-am făcut snippet care îmi generează automat

foo : function(){ var that = this; }

Și tu spui că nu e o problemă? :smiley:

Dar var self = this ce are? :smiley:

LE: sunt impotriva oricarei incercari de a ingreuna lizibilitatea codului (ternary operators, looking at you!) dar arrow functions AR PUTEA fi interesante. Depinde de proiect presupun.

Ma raportam la film, cam pe asta a insistat el, cod mai scurt si mai concis, dar realist vorbind, pe un “real-life code” o sa castige cateva caractere, deci argumentul nu sta in picioare.

Cat despre sintaxa, am precizat ca e o parere subiectiva, asta e, nu mi se pare mai lizibil nici la prima, nici la a doua sau a treia vedere. Deh, obisnuinta.

Am zis ca “nu e chiar asa o problema”, e enervant, admit, doar ca la mine e “self” :slight_smile:

he he he :smiling_imp:

Nu e vorba de salvat bandwidth, ci de a oferi limbajului noi cai de exprimare.
Personal, imi place sintaxa mult, codul e mai compact și mai citibil.
Mi se boring sa scrii si sa citesti function si return in loc de =>

Din JS vNext cea mai tare chestie mi se pare async await. E in [stage 3] (GitHub - tc39/proposals: Tracking ECMAScript Proposals) foarte aproape de a fi adoptat ca standard, dar va lua ceva timp pana cand va fi implementat astfel incat sa nu fie nevoie de Babel.
Am refactorizat niste cod inlocuind callback-uri cu async await, codul devine foarte citibil, e mult mai bine chiar si decat cu promises.

Mai neplacut parca e suportul pentru asa zisele “clase”, mi se pare half cooked. Cred ca termenul de class e putin nefericit, mai bine ii spuneau altfel, sau găseau alta sintaxa.

Arata mai frumos, pana cand nu iti trebuie o foaie ca sa descifrezi de unde incepe si unde se incheie o functie. Ma rog, cu noul ES s-ar putea sa nu mai fie necesara niciodata foaia daca cineva respecta standardele cum trebuie.

Arrow functions arata fain pentru functional programming, dar treaba mai putin buna la ele este la generarea stack trace-urilor si cand facem heap snapshot-uri pentru a descoperi memory leaks. Neavand nume functiile respective, e mai greu de determinat: 1) de unde vine o eroare 2) ce functia a cauzat un memory leak.

1 Like