2016-08-08 16 views
7

W ES6, mogę osiągnąć blok scopingu za sprawy:ES6 blok scoping z przełącznikiem

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

Oczywiście itemId równie dobrze może być podany na górze.
Dla mojego przypadku użycia, zmienne o zasięgu lokalnym mają więcej sensu, ponieważ w moim ogólnym kodzie łatwiej jest określić, co się dzieje, i istnieje pewna liczba case, podczas gdy niektóre bloki zawierają tę zmienną, a inne nie. .

Nie widziałem zakresów bloków używanych jako switch/case jako typowe użycie.
Moje pytanie brzmi po prostu, czy istnieją powody, aby tego nie robić, stylistycznie lub inaczej.

Edycja aktualizowane przykładowy kod, aby uniknąć nieporozumień:

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 mogłyby zostać uznane na górze, ale wolałbym, aby spojrzeć na własność za wypadek. Nie wydaje się, że istnieje bezpośredni powód, aby udostępnić zmienną w różnych przypadkach. Wydaje się również nonsensem wymyślić inną nazwę tego, co zasadniczo jest to samo.

Może to być napisane inaczej, ale ten przykład jest typowym wzorem w architekturze Flux.

+0

Większość czasu, zmienna jest tworzona przed 'switch' i wracający/używane po' switch' w zależności od przypadku. – Tushar

+4

Nie widzę powodu, aby tego nie robić. To jest cały punkt na scopingu na poziomie bloku. Musisz tylko upewnić się, że tworzysz bloki dla '' case's, w przeciwnym razie możesz spróbować ** zdefiniować tę samą zmienną dwukrotnie ** w bloku 'switch ', powodując błąd składni. – Ozan

+3

Powiedziałbym, że istnieją dwa poważne powody, dla których nie jest to powszechne użycie: 1) nie można tego zrobić przed ES6; 2) sytuacje, w których jest to przydatne, nie pojawiają się zbyt często. Nie ma powodu, dla którego nie powinieneś tego robić. – Nit

Odpowiedz

-1

Streszczenie logiki w funkcje. Same instrukcje przełączania są trudne do odczytania, nie mówiąc już o wielu logicznych i zmiennych zakresach. Znacznie lepiej jest objaśnić logikę funkcjom. Również po abstrakcji do funkcji zapewne zauważysz, że nie ma dużej potrzeby, aby instrukcja switch była razem. Zobacz rozdział Avoid use of switch statements poradników stylu DockYard.

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; 
} 

Zobacz, jak instrukcja switch staje się jednym wierszem. Można to łatwo destylowana do słownika odnośnika zamiast:

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

Problem occures powodu przełączyć scenariusz jest traktowany jako pojedynczy blok, niezależnie od indywidualnych statments przypadku, jak „przerwa” oświadczenie jest dobrowolne.

Przepisanie kodu do dalszej powinien wykonać zadanie:

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 
    } 
}