2013-09-26 18 views
10

Ich schaue auf express.js für das Back-End und JS auf der Client-Seite. Meine App ist eine einzelne Seite Web App.node.js und einzelne Seite Webanwendung

Der Server wird nur JSON-Nachrichten und meine Frage ist über "Routing" für Express. Soll man Routing verwenden, um die UI und die serverseitige Geschäftslogik zu verbinden? Wie wird das mit meiner Single-Page-App funktionieren?

Also macht der Client einen Ajax-Aufruf an den Server, der nach einem Wert in der Datenbank sucht, und es gibt ein serverseitiges Skript, das den JSON zurück zur Benutzeroberfläche bereitstellt. Wie wird diese UI- und Node-Skript-Beziehung eingerichtet?

Kann jemand etwas Licht darauf werfen?

+0

Auch wenn Sie dem Client eine einzelne Seite bereitstellen, wird es viele andere Ressourcen geben, mit denen Ihr Anwendungsrouter umgehen muss, externe CSS, JS-Dateien, Bilder, Audio-/Videodateien, Vorlagen und natürlich Ihre REST- oder benutzerdefinierte RPC-Endpunkte, die Ihre einseitige Anwendung zum Abrufen von Daten aufrufen wird. – cbayram

+0

Nicht zu vertraut mit Express, aber überprüfen Sie diese Frage aus http://stackoverflow.com/questions/12695591/node-js-express-jshow-does-app-router-work – cbayram

+0

, um ein JSON zurück zu bekommen Client-Code, um zum Beispiel eine Liste von Büchern zu erhalten, würde ich noch routen/Bücher sogar die App ist einzelne Seite? – reza

Antwort

38

Einzelseiten-Apps sind solche, die von einem einzelnen HTML-Dokument leben. Das heißt, wenn Sie dem Benutzer je nach Zustand der Anwendung verschiedene Inhalte anzeigen möchten, müssen Sie einige DOM-Manipulationen vornehmen (bestimmte Elemente des aktuellen Dokuments mit anderem HTML ausschneiden und ersetzen), um sie zu aktualisieren die 'Ansicht', die der Benutzer sieht. Entschuldigen Sie, wenn dies für Sie offensichtlich ist, nehmen Sie sich bitte nicht beleidigt. Ich dachte, ich würde von hier aus anfangen. Bleib bei mir und ich erkläre dir, wie deine Routing-Situation (mehr oder weniger) ausgeht.

URLs bestehen aus ein paar verschiedenen Teilen, von denen jeder den Browser über bestimmte Informationen informiert, die benötigt werden, um die Ressource herunterzuladen, auf die der Benutzer zugreifen möchte. In der Regel befinden sich die gesuchten Ressourcen irgendwo auf einem Server und der Browser weiß dies aufgrund von Teilen in der URL wie 'Protokoll' ('http:') und 'Host' ('www.mydomain.com') es geht zu diesem Server, um zu finden, was Sie anfordern. Es gibt auch "Abfrage" -Parameter in URLs, die dem Server einige zusätzliche Informationen zu einer bestimmten Aktion wie den Suchbegriffen einer Suchanfrage liefern. Nach den Abfrageparametern kommt der 'Hash'. Der Hash ist, wo die Magie der einzelnen Seite Apps passiert ... eh, gut, irgendwie .....

Zuerst ein bisschen über den Hash. Wenn Sie einer URL ein '#' hinzufügen, interpretiert der Browser die Informationen danach als einen Ort (Element) im aktuell angezeigten Dokument.Das heißt, wenn Sie ein Element mit einer 'id' von 'main' haben und Sie '#main' am Ende der URL hinzufügen, so: 'http: //www.example.com#main', der Browser Scroll '(typischerweise' springen ') an den Anfang dieses Elements, so dass Sie es sehen können. Beachten Sie jedoch, dass wenn Sie 'http://www.example.com/#main' eingeben (wobei der Hash durch einen Schrägstrich von der URL getrennt ist), Sie eine vollständige Neuladung der Seite erzwingen und der Browser versucht, eine Datei mit dem Namen '#main' auf der Server (ich wette, es findet es nicht).

Das Essen zum Mitnehmen ist hier, dass der Browser aus dem aktuellen Dokument nicht weg navigieren wird versuchen, wenn es ein Hash in der URL ist, die Ausnahme natürlich der Fall oben erwähnt, und dies ist groß, weil Single- Seiten-Apps möchten nicht von der Seite weg navigieren oder ein neues Dokument vom Server anfordern. (Sehen Sie, wie das Routing für Einzelseiten-Apps unterschiedlich ist?)

Jetzt ist das Ganze über den Hash nicht wichtig für Einzelseiten-Anwendungen, wie Sie einen machen könnten, ohne mit allem zu tun. Ein Haufen Klick-Handler und DOM-Manipulation ist alles, was Sie wirklich brauchen würden ... Aber das würde bedeuten, dass Benutzer keine Möglichkeit haben, Links zu bestimmten Ansichten in Ihrer App zu teilen. Die URL würde sich niemals ändern und wir könnten niemals direkt zu einer bestimmten Ansicht navigieren. Wir würden immer von der Startposition Ihrer App ausgehen, was leicht eine sehr ärgerliche Situation sein könnte.

Wenn Ihre einseitige Anwendung unterschiedliche Ansichten hat und Sie möchten, dass Benutzer direkt zu bestimmten Lesezeichen oder Lesezeichen navigieren können, müssen Sie ein Routing am Front-End implementieren Zusätzlich zu dem Routing, das Sie im Backend implementieren müssen (Routing für die Daten-API usw.), müssen Sie den Hashwert verwenden.

Ich möchte nicht in wie verschiedene Frameworks führen führen Routing auf dem Front-End, aber es ist im Grunde eine Frage der Aktualisierung der Adressfeld des Browsers, wenn der Benutzer auf einen Link klickt, und die Adressleiste zu sehen, was die Die aktuelle URL lautet und lädt den HTML-Code, der dieser URL zugeordnet ist, in das DOM am angegebenen Speicherort in der Dokumentstruktur.

So haben Sie innerhalb einer Single-Page-App eine Route auf dem Server, die mit dem Rendern des HTML-Dokuments der App (index.html) befasst ist und über Routen, die für den Umgang mit den Daten Ihrer App zuständig sind (Erstellen neuer Instanzen in der Datenbank, An- und Abmelden, Bearbeiten oder Löschen von Instanzen in der Datenbank und Abrufen von Daten ...), die über AJAX-Requests aufgerufen werden.

Dies ist eigentlich eine ziemlich komplizierte Situation, in der HTML5 es uns ermöglicht, auf den Hash-Code zu verzichten (mit Hilfe einiger Neuschreiben auf dem Server) und auch die Schaltflächen "Zurück" und "Weiterleiten" verwenden zu können als hätten wir tatsächlich vom Originaldokument weg navigiert (was wir nicht getan haben, weil wir den Browser nur auf die exakt gleiche URL ausgerichtet haben, nur mit geänderten Hashwerten, so dass keine neuen Seitenladevorgänge stattgefunden haben). Herkömmliche Websitenavigation und -verknüpfung kann erreicht werden, indem die History-API des Browsers verwendet wird, die für IE ab Version 10 verfügbar ist (glaube ich), der Rest der großen Browser-Anbieter war schon etwas früher dran, also Frameworks, die sich nutzen lassen Diese Technologie ermöglicht es Ihren Nutzern, Ihre App ohne den Hash in der URL zu navigieren. Dies zu erklären ist eine Ablenkung und nicht notwendig, um das Routing in Einzelseiten-Apps zu verstehen, aber es ist interessant und du wirst es sowieso lernen müssen, wahrscheinlich ..

AJAX sollte verwendet werden, um JSON vom Server anzufordern. AJAX-Anfragen treffen immer Ihren Server, weil Sie das Hash-Symbol nicht in AJAX-Anfragen einschließen (das wäre lächerlich, weil der Hash nur für das Browsen im Dokument gedacht ist), also müssen serverseitige Routen für die Offenlegung verantwortlich sein Ihre Daten API (Betrachten Sie eine RESTful). Während dies bei einseitigen Apps nicht der einzige Zweck ist, ist es vielleicht der wichtigste.

Soooo, um es zu beenden, werden Sie zwei Sätze von Routen haben. Eine auf dem Client (als Teil eines clientseitigen Frameworks wie AngularJS oder EmberJS, die Liste geht weiter ... Ich bevorzuge Angular, aber es gibt eine ziemlich steile Lernkurve für diesen.) Und einen auf dem Server. Wenn Sie an Serverrouten denken, denken Sie an Daten-API. Wenn Sie an "Seitenrouting" denken, denken Sie daran, dass dies alles auf dem Client gehandhabt wird, durch das Javascript, das Sie mit der ersten Serverantwort geliefert haben (dies ist die einzig notwendige serverseitige Route beim Rendern von HTML in den Browser). Laden Sie Ihre 'index.html' und alle notwendigen Skripte und Stylesheets, etc.). Sie verwenden die Express.static-Middleware, um statische Dateien zu liefern, so dass Sie sich keine Gedanken über die Zuweisung von Routen für diese Dinge machen müssen.

EDIT Eine kurze Erwähnung der AJAX-Implementierung. Auf dem Server haben Sie Routen, die denen ähnlich sind, die Alex als Beispiele angegeben hat, und Sie werden diese URLs vom Client aus aufrufen, indem Sie das Objekt XMLHttpRequest (XHR) verwenden, das von Ihrem Framework oder Ihrer Bibliothek bereitgestellt wird. Es wird nun als mehr oder weniger Standard und Best Practice für Frameworks/Bibliotheken angesehen, diese Anfragen als Promises http://wiki.commonjs.org/wiki/Promises/A zu implementieren. Sie sollten selbst ein wenig darüber lesen, aber ich kann es vielleicht zusammenfassen, indem ich sage, dass es sich um eine asynchrone Operation handelt, die analog zu "versuchen, fangen, werfen" in synchronen Operationen ist. Sie werden ein Zusicherungsobjekt instanziieren und dadurch versuchen, Daten vom Server zu laden, zum Beispiel über eine GET-Anfrage. Stellen Sie sicher, dass Sie Funktionen zur Bearbeitung von Anfragen an die URL, an die Sie die Anfrage gestellt haben (serverseitige Route), vergeben haben! Dieses Objekt, das Sie instanziieren und anschließend die Anfrage an den Server richten, verspricht, das Ergebnis der Anfrage an Sie zurückzugeben, sobald es vom Server zurückkommt (egal ob erfolgreich oder nicht). Wenn es erfolgreich ist, wird es aufgerufen eine Funktion, die Sie geschrieben haben und wird es mit den Daten vom Server liefern. Wenn es fehlschlägt, ruft es eine andere Funktion auf, die auch von Ihnen geschrieben wurde, und liefert es mit dem Fehlerobjekt (oder "Grund" für den Fehler), damit Sie den Fehler entsprechend behandeln können.

Hoffnung, die half, Ihre Frage zu beantworten.

+0

whoa, vielen Dank! Die Zeit, die du gebraucht hast, um es so gut zu erklären. Danke, es hilft sicher. Übrigens habe ich gerade gestern eine großartige Präsentation von Promise/A + gesehen. Sehr nützlich http://www.youtube.com/watch?v=hf1T_AONQJU – reza

+0

Schön, ich bin froh, dass es helfen könnte. Dies war das erste Mal, dass ich tatsächlich zu SO beigetragen habe, was wahrscheinlich ein wenig durcheinander ist, wenn man bedenkt, wie oft ich hier nach Antworten suche ... Welchen Rahmen verwenden Sie, um das Front-End zu erstellen? –

1

Sie müssen nur Anfragen weiterleiten, die Sie dynamisch bedienen. Ihr HTML, CSS, JS sind alle statische Assets. Alles, was Sie für das Routing benötigen, sind Ihre Daten.

Es klingt wie Sie wollen eine Restful API, die im Grunde bedeutet, dass Sie URLs für bestimmte Ressourcen und HTTP-Verben für die Manipulation von ihnen haben.

Etwas wie:

  • GET /books.json - Holen Sie alle Bücher
  • POST /books.json - ein neues Buch mit Eigenschaften im Körper des Antrags erstellen
  • geben
  • GET /books/123.json - Get Buch mit ID von 123
  • PUT /books/123.json - Aktualisieren Sie ein vorhandenes Buch mit Eigenschaften, die im Hauptteil der Anforderung übergeben wurden

This blog post seems to show how to set this up in Express.

Sobald Sie eine vernünftige API liefert JSON haben, stellen Sie einfach Ihre AJAX Anrufe es verwenden, basierend auf welche Objekte Sie holen wollen.

+0

das ist die gängige Praxis für sogar einzelne Seite Anwendungen? Verwenden Sie Routing für Daten und HTML-Seiten beide? – reza

+0

Nein, ich sage, dass Sie _only_ Routen für Daten benötigen. Ihre App ist nur statische Assets. Ihre Daten müssen von Ihrem Server verarbeitet werden. –

+1

möglicherweise ein Codebeispiel Ajax-Aufruf vom Client zum Server würde helfen. Ein Client, der eine Knotenfunktion aufruft, die einen Parameter akzeptiert, kann eine bookId sein – reza

Verwandte Themen