Javascript Namespacing mit RequireJS, warum?

Question

Ich bin derzeit mit diesem Argument über Namespaces auf Javascript konfrontiert und ich brauche eine Community-Meinung.

Das Szenario: Der Architekt verantwortlich für dieses Projekt ist irgendwie RequireJS gewidmet und will es wirklich verwenden.

Ich muss sagen, dass die Anwendung ein Backoffice ist, als Assistent ausgebreitet, also gehen Sie auf 6 Seiten mit einer komplexen Geschäftslogik hin und her, um am Ende etwas zu füllen, das ich hier als Prozess beschreiben kann anfordern.

Ok, keine einzelne Seite Anwendung keine nichts Besonderes in diesen Fragen. Einfache Backoffice-Web-App, mehrseitig, mit einer sehr komplexen Benutzeroberfläche, bei der jede Seite beim Server angefordert wird und alle Ressourcen (CSS, JavaScript usw.) beim Laden der Seite geladen werden müssen.

Hauptfrage: Wissen Sie die Art von App, über die wir sprechen, warum RequireJS in erster Linie?

Zweite Frage: Warum versuchen, zu überzeugen, dass der beste Ansatz für Namespacing in Java Script mithilfe von RequireJS ist? Fehle ich etwas?

Meine Meinung: Für mich macht es überhaupt keinen Sinn. Es ist mühselig, RequireJS hier zu verwenden, weil keine Ressource bei Bedarf geladen wird, sie werden alle beim Laden der Seite geladen (nur weil wir sie alle beim Laden der Seite benötigen). Wir müssen mindestens IE8, Chrome, Firefox und Opera unterstützen und wir hatten schon viel Probleme mit dem Laden der Ressourcen in all diesen Browsern. Es gibt bereits eine Menge Tricks, um sicherzustellen, dass alles wie erwartet über Require geladen wird.

Für Namespace ist es noch schlimmer. Sicher klappt es aber nochmal, scheint mir umständlich und diesbezüglich ist das eigentlich sehr eingeschränkt.

Also fehlt mir etwas? Ich brauche hier eine dritte (oder eine 100ste) Meinung.

• Was halten Sie davon?
• Was verwenden Sie?
• Warum?

Vielen Dank im Voraus

Answer 1

AMD Lader (RequireJS ist ein) befassen sich mit verschiedenen Themen:

• Proper Modularisierung Trennung von Bedenken
• Keine globale Umweltverschmutzung
• Kein Name kollidiert
• Laden nach Bedarf oder Optimierung vor der Bereitstellung
• am Lader Je nach Plugins für erweiterte Themen wie lokalisierte Ressourcen oder Last-Time-Kompilierung

Adressieren Ich bin ein großer Fan von solchen Ladern und finde sie für alles nützlich, aber sehr kleine Single-Seite apps.

Answer 2

Meiner persönlichen Meinung nach ist die Verwendung eines Javascript Modulsystems fast nie eine schlechte Idee. Requirejs ist auch nicht der einzige mögliche Lader für Javascript-Module (aber vielleicht der beliebteste). Einige Alternativen sind LABjs oder HeadJS.

Diese Lader sind oft einfach zu bedienen (nicht viel Ärger am Anfang), können aber sehr helfen, wenn das Projekt immer größer wird. Sie vermeiden die Benennung von Konflikten im globalen Raum und können Sie auch im Bereitstellungsschritt unterstützen, indem Sie Ihre Module minimieren/optimieren. Die wichtigste Tatsache ist, dass Sie mehr modularen JavaScript-Code schreiben können.

• Sie haben einige nützliche Funktionen? Erstellen Sie einfach ein Dienstprogrammmodul.
• Sie haben einige Funktionen, die Sie auf allen Seiten benötigen? setze sie in ein gemeinsames Modul.
• Einige Seiten erfordern viel spezifischen Javascript-Code? Erstellen Sie ein zusätzliches Modul für diese Seiten, damit Sie diesen Code nicht auf anderen Seiten laden müssen.

Answer 3

Egal, ob es sich um eine „einzelne Seite app“ ist oder nicht, hilft RequireJS mit zwei Dinge, die auf eigene ohne viel Entwickler Disziplin nicht leicht sind, wenn Client-Seite JavaScript Entwicklung:

Produktion vs. Entwicklungsumgebung

Es ist mittlerweile normal, dass Sie Ihre JavaScript-Anwendungen in Dateien aufteilen, die logisch den verschiedenen Teilen Ihrer Anwendung ähneln. Es ist einfacher zu debuggen und zu warten. In der Produktion ist jedoch der Versand vieler unkomprimierter Dateien schlecht für die Leistung. So verketten Sie alle Ihre Dateien in einer einzigen Datei, minimieren Sie sie (z. B. mithilfe des Google-Abschlusscompilers) und versenden Sie sie dann als einzelne gezippte Datei. Es gibt viele verschiedene Möglichkeiten, dies mithilfe von Befehlszeilentools zu tun (z. B. GruntJS), aber ohne einen Skriptlader wie RequireJS müssen Sie Ihre Seite für zwei verschiedene Anwendungsfälle einrichten (referenzieren Sie alle Ihre Dev-Dateien als Skript-Tags oder die einzelne Produktion) .js) selbst. RequireJS hat ein NodeJS-Build-Tool, das all dies für Sie erledigt.

Modularisierung

Jetzt ist der Code in separaten Dateien zu halten alles gut. Aber aufgrund der Natur von JavaScript und alles global zu sein bedeutet, dass Sie immer noch in seltsame Dinge wie Namenskonflikte stoßen können. Hier kommt der Namespacing zum Tragen. Aber die noch bessere Alternative ist, alles in eine eigene Funktion zu verpacken (was seinen eigenen Geltungsbereich einführt). Aus diesem Grund kommt der meiste JavaScript-Code in einer selbst ausgeführten anonymen Funktion. Wenn diese Funktion jetzt eine API zurückgibt, die Sie bereitstellen möchten, verfügen Sie über Webmodule. Sie können Ihre Modul-API separat von Ihrer Anwendung testen und an anderen Stellen wiederverwenden.

Lesen Sie auch in der Why Web Modules Abschnitt aus der RequireJS-Dokumentation.

Answer 4

Meine aktuelle Lösung, um die globale Umgebung und Namenskonflikte zu vermeiden, ist $.extend.

Dateisystembaum sieht ungefähr wie folgt aus:

RootFolder 
    +-> js 
    global.js 
    ... 
    +-> views 
     index.js 
     page1.js 
     page2.js 
     ... 
index.html 
page1.html 
page2.html 

So ist es in der Regel eine global.js Datei mit allen Anwendungs ​​gemeinsamen Code und andere spezifische pro Seite.

Für Namespacing mag ich $.erstrecken sich so auf jede JS-Datei Ich habe so etwas wie:

var app = app || {}; 

/* only one document ready block per view if needed */ 
$(document).ready(function(){ 
    /* initialization code */ 
}); 

/* extend the app namespace with the Page1 code */ 
$.extend(app, { 
    page1: { 
     SayHi: function SayHi(name){ 
      alert('Hi ' + name); 
     } 
    } 
}); 

So können Sie Ihren Code zugreifen, indem Sie anrufen:

app.page1.SayHi("Alex"); 

Mit dieser Technik Sie:

• haben die volle Kontrolle über Ihre Code. Keine magische Ressourcenladung und ausgefallene Sachen, die du nicht vollständig kontrollieren kannst.
• Keine globale Umweltverschmutzung
• Keine Namenskonflikte
• Der Namespace-Baum so tief sein können, wie Sie möchten, können Sie der Eigentümer Ihrer eigenen Komplexität sind.
• Sie können mehrere js-Dateien haben, die tatsächlich zur gleichen Namespace-Ebene beitragen. Dies ist besonders hilfreich bei Hilfstools.
• Abhängig von den Javascript-Dateien, die Sie auf der Seite einfügen, können Sie einen größeren oder kleineren App-Namespace haben.

Fazit:

Die Web-Umgebung die wirklich einfach, wir sollten es nicht erschweren.

Ich schlage nicht auf RequireJS, versteh mich nicht falsch. Es macht, wofür es gedacht war (in seiner Essenz ist das pure Resource Lazy Loading). Alles andere ist Zeug, das auch mit dem Paket kommt, aber auch sauberer und transparenter ist.

Also, wenn ich die Hauptfunktion nicht brauche, ist es sinnlos, sie zu benutzen.

Prost!