Tworzenie zmiennych w skryptach działających na DOM

pytanie zadane 8 września 2019 w JavaScript przez mb-dir Mądrala (6,710 p.)

Witam

Chciałbym poznać waszą opinie na temat tworzenia zmiennych w JS, ja przy skryptach które będą działać na DOM 'ubieram' cały takowy skrypt w 'DOMContentLoaded' i wewnątrz tego tworzę wszystko(włącznie z zmiennymi) - przykład. Jednak czasem spotykam się z takim podejściem. Ja jestem bardziej przychylny do pierwszego sposobu, bo nie ma możliwości żeby przypadkowo nadpisać zmienną, jednak chciałbym poznać Waszą opinie.

Pozdrawiam

2 odpowiedzi

odpowiedź 8 września 2019 przez Comandeer Guru (601,450 p.)

Po to stworzono zasięg blokowy, żeby nie robić zmiennych o zasięgu funkcyjnym i globalnym. Stąd to drugie podejście uznałbym za niepoprawne wykorzystanie zmiennej let. Co więcej, tworzymy zmienną możliwą do nadpisania tylko i wyłącznie dlatego, że nie chcemy używać zasięgu blokowego! Czyli zamiast jednego problemu, tworzymy od razu dwa.

Dodatkowo obecnie większość kodu jest pisana z myślą o modułach ES, gdzie problem nadpisywania zmiennych de facto nie istnieje. Wszystkie zmienne pozostają wewnątrz modułu i nie wypływają na zewnątrz. Natomiast używanie takich modułów bezpośrednio w przeglądarce (script[type=module]) rozwiązuje też problem odpalania kodu operującego na DOM dopiero po jego wczytaniu. Wszystkie bowiem moduły odpalają się po wczytaniu DOM, w kolejności, w jakiej występują w kodzie (czyli podobnie do tradycyjnych skryptów z parametrem [defer]). Tym samym można zapomnieć o zdarzeniu DOMContentLoaded.

odpowiedź 8 września 2019 przez adrian17 Ekspert (344,860 p.)

Trzecia opcja: wrzuć skrypty na dół <body> i w ogóle o tym nie myśl.

komentarz 8 września 2019 przez Comandeer Guru (601,450 p.)

No nie do końca, bo takie skrypty nie wczytują się w dokładnie taki sposób, w jaki sobie byśmy najczęściej życzyli → https://addyosmani.com/blog/script-priorities/

komentarz 8 września 2019 przez adrian17 Ekspert (344,860 p.)

Może być też <script defer> (faktycznie jeszcze lepsza opcja), ale z tego co rozumiem, w jego nieobecności w praktyce <script> na dole będą ostatnie w kolejności, no i po parserze - więc sprawdzanie DOMContentLoaded już jest niepotrzebne.

W każdym razie, mój punkt pozostaje - idealnie zrobić to tak, żeby na poziomie JSa nie musieć się tym przejmować :D