2016-08-08 29 views
7

In ES6, I Block Scoping pro Fall erreichen kann:ES6 Block Scoping mit in Schalter

switch(somVar){ 
    case 'first': 
    { 
     let itemId='foo'; 
    } 
    break; 
    case 'second': 
    { 
     let itemId='bar'; 
    } 
} 

Offensichtlich itemId könnte genauso gut auf deklariert werden.
Für meinen Anwendungsfall sind lokal begrenzte Variablen sinnvoller, weil in meinem Gesamtcode leichter erkennbar ist, was passiert, und es gibt eine Reihe von case, während einige Blöcke die fragliche Variable enthalten und andere nicht .

Ich habe Block Scoping nicht für switch/case verwendet als allgemeine Verwendung gesehen.
Meine Frage ist einfach, ob es Gründe gibt, es nicht zu tun, stilistisch oder sonst.

bearbeiten, aktualisiert Beispielcode um Verwirrung zu vermeiden:

const someFunc(action) => { 
    switch(action.type){ 
     case 'first': 
     { 
      let itemId=action.someObj.someProp.id; 
      //Do something with itemId 
     } 
     break; 
     case 'second': 
     { 
      let itemId=action.someObj.someProp.id; 
      //Do something with itemId 
     } 
     break; 
     case 'third': 
      //No use of itemId 
    } 
} 

itemId an der Spitze erklärt werden könnte, aber ich würde auf die Eigenschaft pro Fall suchen bevorzugen. Es scheint keinen unmittelbaren Grund zu geben, die Variable über verschiedene Fälle hinweg zu teilen. Es wäre auch Unsinn, einen anderen Namen für das, was im Wesentlichen das Gleiche ist, zu "erfinden".

Dies könnte wahrscheinlich anders geschrieben werden, aber dieses Beispiel ist ein übliches Muster in Flux-Architektur.

+0

Zeiten Die meisten, eine Variable, bevor 'Schalter' erstellt und zurückgegeben/verwendet, nachdem' Schalter' je nach Fall. – Tushar

+4

Ich sehe keinen Grund, dies nicht zu tun. Dies ist der springende Punkt auf Blockebene. Sie müssen nur sicherstellen, dass Sie Blöcke für Ihre Fälle erstellen, sonst könnten Sie versuchen, ** die gleiche Variable zweimal im Schalterblock zu definieren, was zu einem Syntaxfehler führt. – Ozan

+3

Ich würde sagen, es gibt zwei große Gründe dafür, dass es nicht üblich ist: 1) Du konntest es nicht vor ES6 machen; 2) Situationen, in denen es nützlich ist, kommen nicht zu oft. Es gibt keinen Grund, warum du es nicht tun solltest. – Nit

Antwort

-1

Die Logik in Funktionen zusammenfassen. Switch-Anweisungen selbst sind schwer zu lesen, geschweige denn eine Menge Logik und Variablen-Scoping. Es ist viel besser, die Logik in Funktionen zu abstrahieren. Auch nach dem Abstrahieren von Funktionen werden Sie wahrscheinlich feststellen, dass eine switch-Anweisung nicht alle benötigt wird. Siehe Abschnitt Avoid use of switch statements in den DockYard-Formatvorlagen.

function handleFirstCase() { 
    var itemId = 'foo'; 
    // Do stuff with itemId 
    return expectedValue; 
} 

function handleSecondCase() { 
    var itemId = 'bar'; 
    // Do stuff with itemId 
    return expectedValue; 
} 

let result; 
switch(somVar){ 
case 'first': 
    result = handleFirstCase(); 
    break; 
case 'second': 
    result = handleSecondCase(); 
    break; 
} 

Beachten Sie, wie die Switch-Anweisung eine Zeile wird. Dies kann leicht stattdessen auf eine Wörterbuchsuche destilliert werden:

const CASES = { 
    first() { 
    var itemId = 'foo'; 
    // Do stuff with itemId 
    return expectedValue; 
    }, 

    second() { 
    var itemId = 'bar'; 
    // Do stuff with itemId 
    return expectedValue; 
    } 
}; 

let result = CASES[someVar](); 
1

Das Problem occures aufgrund Szenario wechseln als ein einzelner Block behandelt, unabhängig von den Einzelfall statments, da der ‚Bruch‘ Anweisung ist optional.

Umschreiben von Code auf die folgenden sollte die Arbeit machen:

const someFunc(action) => { 
    if (action.type == 'first'){ 
     let itemId=action.someObj.someProp.id; 
     //Do something with itemId 
    } 
    else if (action.type == 'second'){ 
     let itemId=action.someObj.someProp.id; 
     //Do something with itemId 
    } 
    else { //Third 
     //No use of itemId 
    } 
}