req.locals im Vergleich zu res.locals im Vergleich zu res.data im Vergleich zu req.data im Vergleich zu app.locals in Express-Middleware

Question

Es gibt einige ähnliche Fragen gestellt, aber meine Frage ist, dass, wenn ich Zwischenergebnisse, die ich bekommen propagieren möchte entlang der verschiedenen Routing-Middleware, was ist der beste Weg, das zu tun?

app.use(f1); app.use(f2); app.use(f3); 

function f1(req,res,next) { 
    //some database queries are executed and I get results, say x1 
    res.locals.dbResults = {...}; 
    next(); 
} 

function f2(req,res,next) { 
    // more processing based upon req.locals.dbResults 
    res.locals.moreResults = {....}; 
    next(); 
} 
// ... 

Ich denke, dass ich die gleiche Ausbreitung von Daten durch die verschiedenen Middleware unter Verwendung erf .locals zu bekommen. Es scheint auch so zu sein, dass bei den Anfrage- und Antwortobjekten die Locals-Eigenschaften zu Beginn der Anfrage auf ein leeres Objekt initialisiert wurden.

Auch kann man res.mydata oder req.mydata Eigenschaften auch einstellen?

Theoretisch können app.locals auch verwendet werden, um diese Daten durch die verschiedenen Middleware weiterzuleiten, da sie in den Middlewares bestehen bleiben, aber das wäre im Gegensatz zur herkömmlichen Verwendung von app.locals. Es wird mehr für anwendungsspezifische Daten verwendet. Es wird auch erforderlich sein, diese Daten am Ende des Anfrage-Antwort-Zyklus zu löschen, damit die gleichen Variablen für die nächste Anfrage verwendet werden können.

Was ist der optimale und standardmäßige Weg, um Zwischenergebnisse über Middleware zu verbreiten?

Answer 1

Wie Sie bereits erwähnt haben, können sowohl req.locals, res.locals als auch Ihr eigener definierter Schlüssel res.userData verwendet werden. Abgesehen von der Namensgebung gibt es keinen wirklichen Unterschied. Davon abgesehen, würde ich aber empfehlen res.locals zu verwenden, da dies das einzige in der offiziellen Express.js Dokumentation erwähnt ist:

res.locals Ein Objekt, das Antwort lokale Variablen die enthält scoped Anfrage und daher nur für die Ansicht (en) verfügbar, die während dieses Anfrage/Antwort-Zyklus (falls vorhanden) gerendert wurden. Ansonsten ist diese Eigenschaft identisch mit app.locals.

Diese Eigenschaft ist nützlich, um Informationen auf Anfrageebene wie den Namen des Anfragepfads, authentifizierten Benutzer, Benutzereinstellungen usw. anzuzeigen.

Quelle: http://expressjs.com/en/api.html#res.locals

Weil es offiziell dokumentiert ist, gibt es weniger Chancen, die res.locals Eigenschaft jemals für etwas anderes (Rückwärtskompatibilität) verwendet wird. Wenn Sie Ihren eigenen Schlüssel auswählen, besteht die Möglichkeit, dass zukünftige Versionen von Express.js Ihre Daten überschreiben, da sie denselben Schlüssel verwenden. Dies wird nicht passieren, wenn res.locals verwendet wird. Es erleichtert auch neuen Personen, Ihren Code zu verstehen, da die meisten Projekte res.locals zum Speichern von Middleware-Daten verwenden.