Pytanie w sprawie namespaces, javascript – Dlaczego przestrzenie nazw są uważane za złe praktyki w JavaScript? [Zamknięte]

4

Powiedziano mi, że przestrzenie nazw nie powinny być używane, ponieważ „zanieczyszczają” globalny zasięg. Zastanawiam się, jakie są alternatywy?

Kiedy chcę zdefiniować funkcje użytkowe i / lub stałe, np. w przypadku strony internetowej prostym sposobem byłoby zdefiniowanie ich za pomocą przestrzeni nazw, w ten sposób uszkodzenie globalnego zasięgu jest ograniczone tylko do jednego obiektu.

Jeśli przestrzenie nazw są złymi praktykami, przychodzi na myśl kilka pytań:

Dlaczego ta zła praktyka?Jaki jest zakres tej deklaracji (aplikacje internetowe / dynamiczne strony internetowe / statyczne strony internetowe itp.)?Jakie są alternatywy?

To pytanie jest wynikiem rozpoczętej dyskusjipost na temat korzyści płynących z używania extend.js.

@ FelixKling nie potrzebujesz symboli globalnych. Moduł ładujący jest niezależnym plikiem, który owija się w zamknięcie, a następnie ładuje plik wejściowy za ciebie, a następnie rekursywnie ładuje zależności. Przykład unikania globalnegodefine token dla AMD ładuje moduły jako tekst, a następnieevalWpisują je w zakres zamknięcia, gdziedefine token jest zdefiniowany. Raynos
Ci hipisowscy goście! Zadzwoń do Global Variable Police! Jared Farrish
@Raynos: A jak uzyskać dostęp do modułu ładującego? Potrzebujesztrochę symbol globalny. Nie mówię o tym, że użytkownik powinien tworzyć globalne symbole. Felix Kling
@ Eliran - Podsumowując gorącą retorykę, która tu leci, mniej znaczy lepiej niż dużo (podejście do zmiennych przestrzeni nazw), ale istnieją techniki eliminacji zmiennych globalnych, jak zasugerowałeś. Wszystko sprowadza się do tego, jak do tego podchodzisz i co Ci odpowiada w kodzie. Jared Farrish

Twoja odpowiedź

2   odpowiedź
8

dlaczego ta zła praktyka?

same przestrzenie nazw są złe, ponieważ jest to niepotrzebna koncepcja.

Posiadanie obiektów o właściwościach i metodach jest dopuszczalne. Dobrze jest również mieć token „modułowy”, który jest podobny do „przestrzeni nazw”, ale zamiast tego oznacza to, że masz jeden token „modułu” na plik, który zawiera wszystkie właściwości i metody. Różni się to od „przestrzeni nazw”, ponieważ jest tworzona / zmieniana tylko w jednym pliku i nie jest widoczna jako globalny token.

jaki jest zakres tej deklaracji (aplikacje internetowe / dynamiczne witryny / statyczne strony internetowe itp.)?

Wszystkie ECMAScript, nigdy nie twórz nowych globalnych tokenów

jakie są alternatywy?

Zamiast tego, mając przestrzenie nazw, powinieneś preferować wiele tokenów „lokalnych plików”. Oznacza to, że każdy plik / „moduł” powinien być zapakowany w zamknięcie i powinieneś mieć dostęp do wielu zmiennych lokalnych w tym zamknięciu.

Zmienne globalne są również złe, ponieważ wcale ich nie potrzebujesz. Sposób unikania globali polega na zawijaniu wszystkiego w zamknięcia i inteligentnym ładowaniu zewnętrznych plików javascript.

Przykłady zerowych ładowarek modułów globalnych

przeglądanie węzłówwebmakemodul8

Dalsza lektura:

Modułowość bez globaliModuły CommonJS
Rozumiem co masz na myśli. Jednak sprawia, że ​​ładowanie bibliotek w określonej kolejności (co niestety jest czasami potrzebne w rzeczywistym świecie) lub używanie rzeczy, takich jak polifiltry, trudno powiedzieć co najmniej. Jeśli mogę bezpośrednio użyćdefine irequire w moich tagach skryptowych będę miał większą kontrolę nad radzeniem sobie z nimi. Mimo to zgadzam się, że ogólny kod nie powinien deklarować żadnych globali (i faktycznie usuwam globale ustawione przez biblioteki takie jak jQuery po ich załadowaniu, aby uniknąć przypadkowego powrotu kodu do niektórych globali). Lucero
@ Lèsemajesté> never create new global tokens Nie ma nic złego w dotykaniu lub używaniu istniejących tokenów globalnych. Nie ma też nic złego w globalnej tablicy symboli, która wymusza / chroni przed kolizjami przestrzeni nazw, ale nie ma potrzeby stosowania tej koncepcji przestrzeni nazw. Raynos
Ok, czy ktoś powinien przez to przekopać się i znaleźć kod, który ma sens? Pierwsze myślę Ikliknięty pokazuje pięć zmiennych globalnych. Jared Farrish
Mylicie przestrzenie nazw z obiektami globalnymi lub globalną przestrzenią nazw (żadna z nich nie jest z natury zła). Przestrzenie nazw są bardzo potrzebną koncepcją. Bez tego nie możesz mieć oddzielnych zakresów (jeśli wszystkie lokalne zakresy współdzieliły jedną tablicę symboli, to jest to naprawdę jeden duży zasięg globalny). Masz rację, że korzystanie przez ludzi z globali (niestety niestety) może i powinno się tego unikać. Jednak mając takie obiekty globalnewindow oraz standardowe obiekty w EMCAScript i DOMjest konieczne, jak to jestświatowy obiekty, które muszą być współdzielone wśród całego kodu. Lèse majesté
3

Nie mogę sobie wyobrazić, dlaczego przestrzeń nazw byłaby zła. Chyba że istnieje jakaś definicja przestrzeni nazw specyficzna dla JavaScript, o której nie wiem.

Obecnie pracuję nad małą biblioteką i wszystko jest otoczone przez jeden obiekt najwyższego poziomu (przestrzeń nazw?). Nie umieszczam niczego w oknie ani typach wewnętrznych; jeśli potrzebujesz czegoś z mojej biblioteki, jest dostępna wkilo obiekt.

Dla mnie posiadanie tej „przestrzeni nazw” todobry ćwiczyć, ponieważ pozwala mi to szybko wiedzieć, jeśli dzwonię do metody w mojej bibliotece. Nie ma potrzeby zastępowaniawindow.alert metoda, która może być wkręcona w inną bibliotekę załadowaną na stronie; po prostu użyjkilo.alert dla wersji dostosowanej (jest to wymyślony przykład, ale mam nadzieję, że ma to sens).

Myślę, że potrzebujemy wyraźniejszej definicji przestrzeni nazw. JavaScript ich nie ma, ale mówimy o nich tak, jakby były częścią języka. Naprawdę używam obiektu macierzystego dla mojej biblioteki. Przestrzeń nazw nie jest niczym w JavaScript; nawet to, co nazywa się przestrzenią nazw, jest w rzeczywistości łańcuchem obiektów. kiswa
Nie potrzebujesz „przestrzeni nazw”, aby wiedzieć, czy wywołujesz metodę z biblioteki, po prostu manipulujesz obiektami i tokenami ujawnionymi przez tę bibliotekę. Raynos

Powiązane pytania