Wenn Sie an der Frontend-Entwicklung beteiligt sind, kennen Sie wahrscheinlich die folgenden Mise-en-Scenes: Die Projektbedingungen schrumpfen rapide, Ihr Management oder der Kunde oder beide möchten die funktionierende Anwendung jetzt selbst mit gefälschten Daten mit ihren Augen sehen. Gleichzeitig mag es eine Rückseite geben, aber es ist die API-Ebene der Interaktion mit der Vorderseite, die im Wort überhaupt fehlt.
Vor kurzem war ich mit einer solchen Situation konfrontiert und entwickle ein Frontend für eckige (Leute, die träge auf Stühlen sitzen, jemand nickte verständnisvoll).
Jetzt werde ich es ernsthaft versuchen. Einerseits ist die Situation nicht ungewöhnlich und es können viele Lösungen gewählt werden.
Es kamen mehrere Lösungen in den Sinn:
- Hardcode-Daten auf Komponentenebene
- Hardcode-Daten auf der Ebene der Resolver-Dienste werden an die erforderlichen Routen angeheftet
- Hardcode-Daten auf der Ebene des Datendienstanbieters
- Flush api und gibt gemäß den vereinbarten Verträgen fest codierte Daten zurück
Aber jede dieser Optionen schien eine unerschöpfliche Krücke zu sein, für die es jeweils erhebliche Mängel gab.
- Die erste Option verschwand sofort - eine absolut unpraktische, nicht verwendete Lösung. Während sich das Projekt entwickelt, muss alles neu geschrieben werden.
- Diese Lösung könnte stattfinden, aber auch hier werden die Projektstruktur und die Logik der Komponenten neu geschrieben.
- Als mögliche Option können Sie sogar Stub-Daten asynchron zurückgeben und einen Serveraufruf simulieren. Wie in früheren Lösungen des Problems sind unsere Interceptors (sofern vorhanden, aber vorhanden) arbeitslos, und es stellt sich heraus, dass die Nachahmung der Arbeit erfolgt mit Unterstützung wird unvollständig.
- Die letzte Option schien durchaus akzeptabel zu sein, ohne die Probleme, die die vorherigen Optionen hatten, aber ich wollte aus hygienischen Gründen keinen Hardcode in das Backend-Projekt schreiben.
Infolgedessen wurde eine andere Option ausgewählt: einen separaten Webserver zu erstellen, der Daten gemäß Routen und Verträgen zurückgibt, und eine separate Konfiguration für die Montage und Ausführung von Angular zu konfigurieren. Es stellte sich heraus, dass es einfach war, beides zu tun.
Um den Mock-Server zu implementieren, wurde
Express ausgewählt.
Beginnen wir damit.
Wir wählen den Ort, an dem wir Code für den msk-Server schreiben möchten, beispielsweise im Mock-Server-Verzeichnis neben dem ng-Projekt.
Als nächstes müssen Sie das Projekt initialisieren und das Paket mit Express hinzufügen.
npm init
npm install --save express
Fügen Sie als Nächstes einen Code hinzu, der Daten an uns zurückgibt. Wir erstellen die Datei index.js und übernehmen den Code aus dem ersten Tutorial.
const express = require("express"); const app = express(); app.get("/url", (req, res, next) => { res.json(["Tony", "Lisa", "Michael", "Ginger", "Food"]); }); app.listen(3000, () => { console.log("Server running on port 3000"); });
Starten Sie den Server
node index.js
Fragen Sie beim Postboten nach:
Alles ist super, der Server funktioniert. Konfigurieren wir nun eine der Routen, als würden wir Daten von einer echten API anfordern. Angenommen, wir benötigen eine Liste aller Bücher. Füllen Sie die Datei books.json mit Büchern
[ { "rn": 0, "id": "0", "name": "Jungle", "type": 0, "wells": 10042, "default": false, "hidden": false, "author": "Admin" }, { "rn": 1, "id": "1", "name": "Main", "type": 1, "wells": 156, "default": true, "hidden": false, "author": "User" } ]
Und aktualisieren Sie die Anwendungsdatei:
const express = require("express"); const app = express(); app.get("/api/book/", (req, res, next) => { const books = require('./books'); res.json(books); }); app.listen(3000, () => { console.log("Server running on port 3000"); });
Und überprüfen Sie:
Großartig.
Beginnen wir jetzt mit der eckigen App.
Fügen Sie die Konfiguration, in der die Adresse gespeichert ist, zu den Umgebungen / Umgebungen * .ts-Dateien hinzu.
Umwelt.ts:
export const environment = { production: false, backend: 'http://localhost:5000/' }
environment.prod.ts
export const environment = { production: true, backend: 'http://localhost:5000/' }
Im normalen Modus und im Produkt- und Entwicklungsmodus suchen wir wie oben beschrieben nach der .net-Kern-API auf Port 5000. Als nächstes beschreiben wir die Konfiguration für die temporäre Zurück
environment.mock.ts
export const environment = { production: false, backend: 'http://localhost:3000/' }
Wie Sie sehen, suchen wir hier nach API auf Port 3000, wo wir Express ausführen werden.
Jetzt benötigen wir einen Interceptor, der je nach Konfiguration Anrufe nach hinten an den richtigen Server weiterleitet.
@Injectable() export class RequestInterceptor implements HttpInterceptor { baseUrl: string; constructor() { this.baseUrl = environment.backend; } intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { return next.handle(this.modifyRequest(req)); } private modifyRequest = (req: HttpRequest<any>): HttpRequest<any> => { if (req.url.startsWith('api/')) { const url = this.baseUrl; req = req.clone({ url: url + req.url }); } return req; } }
Die neue Konfiguration für das Zusammenstellen und Starten der Anwendung für die Arbeit mit dem Mock-Server muss noch konfiguriert werden.
Dazu müssen wir angle.json ein wenig optimieren.
Fügen Sie im Abschnitt Ihres Projekts, Architekt / Build / Konfigurationen, eine neue Mock-Build-Konfiguration hinzu und beschreiben Sie das Ersetzen von Umgebungsdateien für diese Konfiguration. Erstellen Sie auch für den Serve-Modus eine Scheinkonfiguration und geben Sie die gewünschte Build-Option an
{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", "version": 1, "newProjectRoot": "projects", "projects": { "your-project": { /*****/ "architect": { "build": { /*****/ "configurations": { "production": { /*****/ }, "mock": { "fileReplacements": [ { "replace": "src/environments/environment.ts", "with": "src/environments/environment.mock.ts" } ] } } }, "serve": { "builder": "@angular-devkit/build-angular:dev-server", "options": { "browserTarget": "your-project:build" }, "configurations": { "production": { "browserTarget": "your-project:build:production" }, "mock": { "browserTarget": "your-project:build:mock" } } } }, /*****/ } } }
Das ist alles, jetzt bleibt es, das Projekt in der gewünschten Konfiguration auszuführen
ng serve --configuration=mock
und überprüfen Sie, wo Anrufe nach hinten wegfliegen:
Alles in Ordnung ist.
Tatsächlich wird uns dieses Design immer noch sehr helfen, wenn wir die Integration und die e2e-Tests für das Projekt verschärfen. Ich werde versuchen, in naher Zukunft darüber zu schreiben.