ES6 ha immediatamente richiamato la funzione freccia

Perché funziona in una Node.jsconsole (testato in 4.1.1 e 5.3.0) ma non funziona nel browser (testato in Chrome)? Questo blocco di codice dovrebbe creare e richiamare una funzione anonima che registra Ok.

() => {
  console.log('Ok');
}()

Inoltre, mentre quanto sopra funziona in Node, questo non funziona:

n => {
  console.log('Ok');
}()

Né questo:

(n) => {
  console.log('Ok');
}()

La cosa strana è che quando viene aggiunto il parametro, viene effettivamente lanciato un SyntaxErrornella parte che invoca immediatamente.

Devi renderlo un'espressione della funzione invece della definizione della funzione che non ha bisogno di un nome e lo rende un JavaScript valido.

(() => {
  console.log('Ok');
})()

È l'equivalente di IIFE

(function(){
   console.log('Ok')
})();

E il possibile motivo per cui funziona in Node.js ma non in Chrome è perché il suo parser lo interpreta come una funzione auto-eseguibile, in quanto

function() { console.log('hello'); }();

funziona bene in Node.jsQuesta è un'espressione di funzione e chrome e firefox e la maggior parte del browser la interpreta in questo modo. Devi invocarlo manualmente.

Il modo più ampiamente accettato di dire al parser di aspettarsi che un'espressione di funzione sia semplicemente racchiuderla in parentesi, perché in JavaScript le parentesi non possono contenere istruzioni. A questo punto, quando il parser incontra la parola chiave della funzione, sa analizzarla come espressione di funzione e non come dichiarazione di funzione.

Per quanto riguarda la versione parametrizzata , funzionerà.

((n) => {
  console.log('Ok');
})()

Nessuno di questi dovrebbe funzionare senza parentesi.

Perché?

Perché secondo le specifiche:

1. ArrowFunction è elencato in AssignmentExpression
2. L' LHS di una CallExpression deve essere MemberExpression , SuperCall o CallExpression

Quindi un ArrowFunction non può essere sull'LHS di un CallExpression .

Ciò che ciò significa effettivamente in come =>dovrebbe essere interpretato è che funziona allo stesso livello di operatori di assegnazione =, +=ecc.

Senso

• x => {foo}() non diventa(x => {foo})()
• L'interprete cerca di interpretarlo come x => ({foo}())
• Quindi è ancora un SyntaxError
• Quindi l'interprete decide che (deve essere stato sbagliato e lancia un SyntaxError

C'era un bug su Babel su di esso qui , anche.

Il motivo per cui stai riscontrando problemi come questo è che la console stessa tenta di emulare l'ambito globale del contesto al quale stai attualmente mirando. Prova anche a catturare i valori di ritorno dalle istruzioni e dalle espressioni che scrivi nella console, in modo che vengano visualizzati come risultati. Prendi ad esempio:

> 3 + 2
< 5

Qui, viene eseguito come se fosse un'espressione, ma l'hai scritto come se fosse un'affermazione. Negli script normali, il valore verrebbe scartato, ma qui il codice deve essere alterato internamente (come se si racchiudesse l'intera istruzione con un contesto di funzione e returnun'istruzione), che causa tutti i tipi di strani effetti, compresi i problemi che si verificano.

Questo è anche uno dei motivi per cui alcuni codici ES6 nudi negli script funzionano bene ma non nella console di Chrome Dev Tools.

Prova a eseguirlo nella console Node e Chrome:

{ let a = 3 }

In Node o in un <script>tag funziona bene, ma nella console dà Uncaught SyntaxError: Unexpected identifier. Ti dà anche un link alla fonte sotto forma di VMxxx:1cui puoi fare clic per ispezionare la fonte valutata, che si presenta come:

({ let a = 3 })

Quindi perché lo ha fatto?

La risposta è che deve convertire il codice in un'espressione in modo che il risultato possa essere restituito al chiamante e visualizzato nella console. Puoi farlo avvolgendo l'istruzione tra parentesi, il che la rende un'espressione, ma rende anche sintatticamente errato il blocco sopra (un'espressione non può avere una dichiarazione di blocco).

La console cerca di risolvere questi casi limite essendo intelligente riguardo al codice, ma questo va oltre lo scopo di questa risposta, credo. Puoi presentare un bug per vedere se è qualcosa che potrebbero prendere in considerazione.

Ecco un buon esempio di qualcosa di molto simile:

https://stackoverflow.com/a/28431346/46588

Il modo più sicuro per far funzionare il codice è assicurarsi che possa essere eseguito come espressione e ispezionare il SyntaxErrorcollegamento di origine per vedere qual è il codice di esecuzione effettivo e decodificare una soluzione da quello. Di solito significa una coppia di parentesi posizionate strategicamente.

In breve: la console tenta di emulare il contesto di esecuzione globale nel modo più accurato possibile, ma a causa dei limiti di interazione con il motore v8 e la semantica JavaScript, questo è talvolta difficile o impossibile da risolvere.

Ho fatto una domanda come questa:

@getify Ho questa domanda: per produrre un modello #IIFE usiamo i paran attorno a una dichiarazione di funzione per trasformarla in un'espressione di funzione e quindi invocarla. Ora nella funzione freccia IIFE, perché abbiamo bisogno di paran ?! La funzione freccia non è già un'espressione per impostazione predefinita ?!

e questa è la risposta di Kyle Simpson:

una funzione freccia è un'espr, ma abbiamo bisogno delle parentesi circostanti b / c di "precedenza dell'operatore" (sorta), in modo che le parentesi finali per invocare la freccia-IIFE si applichino all'intera funzione e non solo all'ultimo token del suo corpo .

x => console.log(x)(4)

vs

(x => console.log(x))(4)

- getify (@getify) 12 giugno 2020