Req.locals vs. res.locals vs. res.data vs. req.data vs. app.locals в промежуточном программном обеспечении Express

Есть несколько похожих вопросов, но мой вопрос заключается в том, что если я хочу распространять промежуточные результаты, которые я получаю по разному промежуточному программному обеспечению маршрутизации, что это лучший способ сделать это?

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();

} ...

Я думаю, что я могу получить такое же распространение данных через другое промежуточное ПО, используя req.locals. Кроме того, похоже, что объекты запроса и ответа имеют свойства locals, инициализированные пустым объектом в начале запроса.

Кроме того, можно также задать свойства res.mydata или req.mydata?

В теории, app.locals также может использоваться для передачи этих данных через различное промежуточное программное обеспечение, поскольку оно будет сохраняться у посредников, но это противоречило бы традиционному использованию app.locals. Он больше используется для конкретных приложений. Также необходимо будет очистить эти данные в конце цикла запроса-ответа, чтобы для следующего запроса могли использоваться одни и те же переменные.

Каков оптимальный и стандартный способ распространения промежуточных результатов через промежуточное программное обеспечение?

Ответ 1

Как вы уже упоминали, могут использоваться как req.locals, res.locals, так и ваш собственный определенный ключ res.userData. Помимо называния, нет никакой реальной разницы. Тем не менее, я бы [strong > рекомендовал использовать res.locals, поскольку это единственный, упомянутый в официальной документации Express.js:

res.localsОбъект, содержащий локальные переменные ответа, привязанные к запросу, и, следовательно, доступный только для визуализированных представлений во время этого цикла запроса/ответа (если есть). В противном случае это свойство идентично app.locals.

Это свойство полезно для отображения информации на уровне запроса, такой как имя пути запроса, аутентифицированный пользователь, пользовательские настройки и т.д.

Источник: http://expressjs.com/en/api.html#res.locals

Поскольку он официально задокументирован, меньше вероятность использования свойства res.locals для чего-либо еще (обратная совместимость). Если вы выбираете свой собственный ключ, всегда есть вероятность, что будущие версии Express.js перезапишут ваши данные, потому что они используют один и тот же ключ. Этого не произойдет при использовании res.locals. Это также облегчает понимание людьми нового кода, поскольку большинство проектов используют res.locals для хранения данных промежуточного слоя.