Frage an javascript, namespaces – Warum werden Namespaces in JavaScript als schlechte Praxis angesehen? [geschlossen]

4

Mir wurde gesagt, Namespaces sollten nicht verwendet werden, da sie den globalen Geltungsbereich "verschmutzen". Ich frage mich, was sind die Alternativen?

Wenn ich Utility-Funktionen und / oder Konstanten definieren möchte, z. Für eine Website wäre es ein einfacher Weg, sie über Namespaces zu definieren. Auf diese Weise wird der Schaden für den globalen Bereich auf nur ein Objekt beschränkt.

Wenn Namespaces eine schlechte Praxis sind, kommen ein paar Fragen in den Sinn:

Warum ist diese schlechte Praxis?Welchen Umfang hat diese Erklärung (Webanwendungen / dynamische Websites / statische Websites usw.)?Was sind die Alternativen?

Diese Frage ist das Ergebnis einer Diskussion überEin Beitrag über die Vorteile der Verwendung von extend.js.

Diese Hippie-Namespacer! Rufen Sie die Global Variable Police an! Jared Farrish
@Raynos: Und wie greifen Sie auf den Modul-Loader zu? Du brauchstetwas globales Symbol. Ich spreche nicht davon, dass der Benutzer globale Symbole erstellen sollte. Felix Kling
Und ich dachte immer, dass Namespaces genau dafür sindnicht den globalen Geltungsbereich verschmutzen ... (-> Sie sindgut). Felix Kling
@FelixKling benutzerdefinierte Modullader mit Verschlüssen. Bibliotheken sollten keine globalen Token verfügbar machen, sondern ihre Module in einem Standardformat wie AMD oder commonJS verfügbar machen. Modullader sollten diese Module extrahieren und die Abhängigkeiten zwischen Modulen behandeln. Dies kann mit null vom Benutzer erstellten globalen Token durchgeführt werden (sogar unter Vermeidung temporärer globaler Token). Raynos

Deine Antwort

2   die antwort
8

Warum ist das eine schlechte Praxis?

Namespaces selbst sind schlecht, weil es ein unnötiges Konzept ist.

Es ist akzeptabel, Objekte mit Eigenschaften und Methoden zu haben. Es ist auch in Ordnung, ein "Modul" -Token zu haben, das einem "Namespace" ähnelt. Stattdessen bedeutet dies, dass Sie ein "Modul" -Token pro Datei haben, das alle Ihre Eigenschaften und Methoden enthält. Dies unterscheidet sich von einem "Namespace", da er nur in einer einzelnen Datei erstellt / geändert und nicht als globales Token verfügbar gemacht wird.

Welchen Umfang hat diese Erklärung (Webanwendungen / dynamische Websites / statische Websites usw.)?

Alle ECMAScript, erstellen Sie niemals neue globale Token

Was sind die Alternativen?

Statt Namespaces zu haben, sollten Sie mehrere "file local" -Token bevorzugen. Das bedeutet, dass jede Datei / jedes "Modul" in einen Abschluss eingeschlossen werden soll und Sie Zugriff auf mehrere lokale Variablen innerhalb dieses Abschlusses haben sollen.

Globale Variablen sind auch schlecht, weil Sie sie überhaupt nicht brauchen. Die Art und Weise, wie Sie Globals vermeiden, besteht darin, alles in Closures zu verpacken und beim Laden externer Javascript-Dateien intelligent zu sein.

Beispiele für null globale Modullader

Node-Browserifywebmakemodul8

Weitere Lektüre:

Modularität ohne GlobaleCommonJS-Module
@JaredFarrishNode-Browserify Null Globale. Raynos
Es werden keine globalen Werte benötigt. Sie können die Token injizierendefine undrequire in Module durch andere als globale Token Raynos
@ Lèsemajesté> never create new global tokens Es ist nichts Falsches daran, vorhandene globale Token zu berühren oder zu verwenden. An einer globalen Symboltabelle, die Namespace-Kollisionen erzwingt / schützt, ist ebenfalls nichts auszusetzen, aber dieses Namespace-Konzept ist nicht erforderlich. Raynos
Entschuldigung, aber du hast mich hier verloren. Wenn ich einen AMD-kompatiblen Loader verwende und ein Modul definieren möchte, tue ich dasdefine(...) - sodefine muss für mich da sein um als global zu nutzen, nein? (Natürlich nicht von mir, sondern vom AMD-Loader definiert.) Dasselbe gilt für das Laden und Ausführen von Code, der Module verwendet, die ich dort benötigerequire. Lucero
3

Ich kann mir nicht vorstellen, warum ein Namespace eine schlechte Sache wäre. Es sei denn, es gibt eine JavaScript-spezifische Definition des Namespace, die mir nicht bekannt ist.

Ich arbeite gerade an einer kleinen Bibliothek, und alles ist in einem Objekt der obersten Ebene (Namespace?) Eingeschlossen. Ich lege nichts auf das Fenster oder die eigentlichen Typen; Wenn Sie etwas aus meiner Bibliothek benötigen, finden Sie es in derkilo Objekt.

Für mich ist der Namespace agut Üben Sie, da ich sehr schnell weiß, ob ich eine Methode in meiner Bibliothek aufrufe. Es besteht keine Notwendigkeit, die zu überschreibenwindow.alert Methode, die mit einer anderen auf der Seite geladenen Bibliothek verschraubt werden könnte; benutz einfachkilo.alert für die angepasste Version (dies ist ein erfundenes Beispiel, aber ich hoffe, es macht den Punkt).

Ich denke, wir brauchen eine klarere Definition des Namensraums. JavaScript hat sie nicht, aber wir reden über sie, als ob sie tatsächlich Teil der Sprache sind. Eigentlich verwende ich nur ein übergeordnetes Objekt für meine Bibliothek. Ein Namespace ist in JavaScript eigentlich keine Sache. Sogar was hier als Namespace bezeichnet wird, ist eigentlich nur eine Kette von Objekten. kiswa
Sie benötigen keinen Namespace, um festzustellen, ob Sie eine Methode aus einer Bibliothek aufrufen. Sie manipulieren lediglich die Objekte und Token, die von dieser Bibliothek verfügbar gemacht werden. Raynos

Verwandte Fragen