We Keep Coding

Is there a way in Node.js to create global variables that live only for the lifetime of the request? [duplicate]

I want to pass some variable from the first middleware to another middleware, and I tried doing this, but there was "req.somevariable is a given as 'undefined'".
//app.js
..
app.get('/someurl/', middleware1, middleware2)
...
////middleware1
...
some conditions
...
res.somevariable = variable1;
next();
...
////middleware2
...
some conditions
...
variable = req.somevariable;
...

v4.x API docs
This is what the res.locals object is for. Setting variables directly on the request object is not supported or documented. res.locals is guaranteed to hold state over the life of a request.
Quote from the docs:
An object that contains response local variables scoped to the
request, and therefore available only to the view(s) rendered during
that request / response cycle (if any). Otherwise, this property is
identical to app.locals.
This property is useful for exposing request-level information such as
the request path name, authenticated user, user settings, and so on.
app.use(function(req, res, next) {
res.locals.user = req.user;
res.locals.authenticated = !req.user.anonymous;
next();
});
To retrieve the variable in the next middleware:
app.use(function(req, res, next) {
if (res.locals.authenticated) {
console.log(res.locals.user.id);
}
next();
});

Attach your variable to the res.locals object, not req.
Instead of
req.somevariable = variable1;
Have:
res.locals.somevariable = variable1;
As others have pointed out, res.locals is the recommended way of passing data through middleware.

I don't think that best practice will be passing a variable like req.YOUR_VAR. You might want to consider req.YOUR_APP_NAME.YOUR_VAR or req.mw_params.YOUR_VAR.
It will help you avoid overwriting other attributes.

The most common pattern for passing variables on to other middleware and endpoint functions is attaching values to the request object req.
In your case, that would mean having middlewares such as these:
app.use(function (req, res, next) {
req.someVariable = 123;
next();
});
app.use(function (req, res, next) {
console.log("The variable is", req.someVariable);
next();
});
There are many common use cases of this pattern, and it is the standard way of doing it in the express community. See, for example:
express.json, which ships with express, previously part of body-parser which follows the same pattern for all request parsing.
multer used for parsing multipart data
express-jwt
express-validator (see code)
express-session
express-useragent
express-pino-logger
express-bunyan-logger
It is worth noting that the currently most highly voted answer incorrectly recommends using res.locals for this purpose---which seems to stem from a misreading of the documentation. For that reason, I'll elaborate on why this is not the usual approach to the problem (although it isn't particularly harmful either).
The documentation
As supporting evidence for the res.locals approach being the appropriate one for the case, the now outdated documentation is cited:
An object that contains response local variables scoped to the request, and therefore available only to the view(s) rendered during that request / response cycle (if any). Otherwise, this property is identical to app.locals.
This property is useful for exposing request-level information such as the request path name, authenticated user, user settings, and so on.
Note the framing here: res.locals is for variables only available "to the view(s) rendered during that request" (emphasis added).
That is what res.locals relates to. res.render renders some template file with some given data as well as access to the locals. This was actually more clear in the v2 docs, and we've now updated the current Express documentation to be clearer:
Use this property to set variables accessible in templates rendered with res.render. The variables set on res.locals are available within a single request-response cycle, and will not be shared between requests.
In order to keep local variables for use in template rendering between requests, use app.locals instead.
This property is useful for exposing request-level information such as the request path name, authenticated user, user settings, and so on to templates rendered within the application.
(Emphasis added.)
The guide
Further evidence of extending req being the standard approach is found in the guide on Writing Middleware, which states:
Next, we’ll create a middleware function called “requestTime” and add a property called requestTime to the request object.
const requestTime = function (req, res, next) {
req.requestTime = Date.now()
next()
}
When this was mentioned in discussion in the answers on this here question, one user responded: "This was the way you'd do it before they added res.locals so might be old docs. res.locals is a namespace specifically for this."
This doesn't track with the history of the codebase, however: locals have been present since v2, which is significantly before e.g. express.json was included in the library, at which point it would have made sense to change the behvaior, if it was indeed correct to save values in res.locals.
Closing notes
Shoutout to #real_ate who wrote in the comments, but was overlooked.

That's because req and res are two different objects.
You need to look for the property on the same object you added it to.

The trick is pretty simple... The request cycle is still pretty much alive. You can just add a new variable that will create a temporary, calling
app.get('some/url/endpoint', middleware1, middleware2);
Since you can handle your request in the first middleware
(req, res, next) => {
var yourvalue = anyvalue
}
In middleware 1 you handle your logic and store your value like below:
req.anyvariable = yourvalue
In middleware 2 you can catch this value from middleware 1 doing the following:
(req, res, next) => {
var storedvalue = req.yourvalue
}

As mentioned above, res.locals is a good (recommended) way to do this. See here for a quick tutorial on how to do this in Express.

SailsJS proper way to pass an object/variable to a layout view

Hello I was wondering if there is a proper way to pass a variable or object to a layout view?
This is what I'm doing at the moment and it works
index: function(req, res){
res.view({ layout: 'mylayout', myvar: 'This is a view var' });
}
But on every action I have to define 'myvar' so I can use it at the layout level, so what I would like to know if there is some kind of controller or action for layouts so I can place there my logic?

Actually starting with Sails v0.10-rc5, you can use sails.config.views.locals hash to specify variables that should be provided by default to all views. So in config/views.js, something like:
{
locals: {
myvar : 'this is a view var'
}
}
would add the var to every view. This is mostly useful for variables that affect the view engine; see here for more details.
You can also use a policy in Sails v0.10.x to set vars across multiple views, by altering req.options.locals. So if you created a policy /api/policies/decorate.js with:
module.exports = function(req, res, next) {
// Default to an object if empty, or use existing locals that may have
// been set elsewhere
req.options.locals = req.options.locals || {};
// Set a new local var that will be available to any controller that
// implements the policy
req.options.locals.myVar = Math.random()
and then set up your /config/policies.js with something like:
module.exports = {
'*': 'decorate'
}
then any controller action that uses res.view will have that myVar variable available in the view.

It depends on the layout engine you have configured with sails (ejs is default). However passing a variable to a view is commonly done like this:
index: function(req, res){
res.view({ layout: 'mylayout', myModel: modelObj });
}
You have to inject the model in every view that uses it. If you want to register the model a globally you have to use a custom middleware like described here: How to create global variables accessible in all views using Express / Node.JS?

You can use config.views.locals, but i like to keep this out of the config folder and put it in the api/services directory. I call it api/services/page.js
then add some variable and other view helpers if you want.
module.exports = {
title:'test',
appName: 'My App Name',
getBlueprintPath: function (path) {
return sails.config.blueprints.prefix + path;
},
};
then in my view i have
<%= page.appName %>
the advantage of doing this way is your logic is kept inside api directory. You can still set locals for the view and not accidentally override some variable you had previously set in config.views.local.

expressjs conditional view render path

I'm writing an app using expressjs. I have my views in, commonly, /views folder. They cover 90% of my customers' needs, but sometimes I have to override one or another of those view to add custom-tailored features. I really wonder I can build a folder structure like:
*{ ...other expressjs files and folders...}*
/views
view1.jade
view2.jade
view2.jade
/customerA
view2.jade
/customerB
view3.jade
What I'd like is to override the behaviour of expressjs' response.render() function to apply the following algorithm:
1. a customer requests a view
2. if /{customer_folder}/{view_name}.jade exists, than
render /{customer_folder}/{view_name}.jade
else
render /views/{view_name}.jade
Thus, for customerA, response.render('view1') will refer to /views/view1.jade while response.render('view2') will refer to /customerA/view2.jade
(those who use appcelerator's titanium may sound it familiar)
I'd like an elegant way to implement this behavior without the hassle of modify expressjs' core functionality, and thus possibly get treated at upgrading my framework. I guess it's a common problem but I can't find any article on the web.

I would create a custom View class:
var express = require('express');
var app = express();
var View = app.get('view');
var MyView = function(name, options) {
View.call(this, name, options);
};
MyView.prototype = Object.create(View.prototype);
MyView.prototype.lookup = function(path) {
// `path` contains the template name to look up, so here you can perform
// your customer-specific lookups and change `path` so that it points to
// the correct file for the customer...
...
// when done, just call the original lookup method.
return View.prototype.lookup.call(this, path);
};
app.set('view', MyView);

You can hook http.ServerResponse.render.
Here's some code from the top of my head, to be used as middleware:
var backup = res.render
res.render = function() {
//Do your thing with the arguments array, maybe use environment variables
backup.apply(res, arguments) //Function.prototype.apply calls a function in context of argument 1, with argument 2 being the argument array for the actual call
}

Passing variables to the next middleware using next() in Express.js

I want to pass some variable from the first middleware to another middleware, and I tried doing this, but there was "req.somevariable is a given as 'undefined'".
//app.js
..
app.get('/someurl/', middleware1, middleware2)
...
////middleware1
...
some conditions
...
res.somevariable = variable1;
next();
...
////middleware2
...
some conditions
...
variable = req.somevariable;
...

v4.x API docs
This is what the res.locals object is for. Setting variables directly on the request object is not supported or documented. res.locals is guaranteed to hold state over the life of a request.
Quote from the docs:
An object that contains response local variables scoped to the
request, and therefore available only to the view(s) rendered during
that request / response cycle (if any). Otherwise, this property is
identical to app.locals.
This property is useful for exposing request-level information such as
the request path name, authenticated user, user settings, and so on.
app.use(function(req, res, next) {
res.locals.user = req.user;
res.locals.authenticated = !req.user.anonymous;
next();
});
To retrieve the variable in the next middleware:
app.use(function(req, res, next) {
if (res.locals.authenticated) {
console.log(res.locals.user.id);
}
next();
});

Attach your variable to the res.locals object, not req.
Instead of
req.somevariable = variable1;
Have:
res.locals.somevariable = variable1;
As others have pointed out, res.locals is the recommended way of passing data through middleware.

I don't think that best practice will be passing a variable like req.YOUR_VAR. You might want to consider req.YOUR_APP_NAME.YOUR_VAR or req.mw_params.YOUR_VAR.
It will help you avoid overwriting other attributes.

The most common pattern for passing variables on to other middleware and endpoint functions is attaching values to the request object req.
In your case, that would mean having middlewares such as these:
app.use(function (req, res, next) {
req.someVariable = 123;
next();
});
app.use(function (req, res, next) {
console.log("The variable is", req.someVariable);
next();
});
There are many common use cases of this pattern, and it is the standard way of doing it in the express community. See, for example:
express.json, which ships with express, previously part of body-parser which follows the same pattern for all request parsing.
multer used for parsing multipart data
express-jwt
express-validator (see code)
express-session
express-useragent
express-pino-logger
express-bunyan-logger
It is worth noting that the currently most highly voted answer incorrectly recommends using res.locals for this purpose---which seems to stem from a misreading of the documentation. For that reason, I'll elaborate on why this is not the usual approach to the problem (although it isn't particularly harmful either).
The documentation
As supporting evidence for the res.locals approach being the appropriate one for the case, the now outdated documentation is cited:
An object that contains response local variables scoped to the request, and therefore available only to the view(s) rendered during that request / response cycle (if any). Otherwise, this property is identical to app.locals.
This property is useful for exposing request-level information such as the request path name, authenticated user, user settings, and so on.
Note the framing here: res.locals is for variables only available "to the view(s) rendered during that request" (emphasis added).
That is what res.locals relates to. res.render renders some template file with some given data as well as access to the locals. This was actually more clear in the v2 docs, and we've now updated the current Express documentation to be clearer:
Use this property to set variables accessible in templates rendered with res.render. The variables set on res.locals are available within a single request-response cycle, and will not be shared between requests.
In order to keep local variables for use in template rendering between requests, use app.locals instead.
This property is useful for exposing request-level information such as the request path name, authenticated user, user settings, and so on to templates rendered within the application.
(Emphasis added.)
The guide
Further evidence of extending req being the standard approach is found in the guide on Writing Middleware, which states:
Next, we’ll create a middleware function called “requestTime” and add a property called requestTime to the request object.
const requestTime = function (req, res, next) {
req.requestTime = Date.now()
next()
}
When this was mentioned in discussion in the answers on this here question, one user responded: "This was the way you'd do it before they added res.locals so might be old docs. res.locals is a namespace specifically for this."
This doesn't track with the history of the codebase, however: locals have been present since v2, which is significantly before e.g. express.json was included in the library, at which point it would have made sense to change the behvaior, if it was indeed correct to save values in res.locals.
Closing notes
Shoutout to #real_ate who wrote in the comments, but was overlooked.

That's because req and res are two different objects.
You need to look for the property on the same object you added it to.

The trick is pretty simple... The request cycle is still pretty much alive. You can just add a new variable that will create a temporary, calling
app.get('some/url/endpoint', middleware1, middleware2);
Since you can handle your request in the first middleware
(req, res, next) => {
var yourvalue = anyvalue
}
In middleware 1 you handle your logic and store your value like below:
req.anyvariable = yourvalue
In middleware 2 you can catch this value from middleware 1 doing the following:
(req, res, next) => {
var storedvalue = req.yourvalue
}

As mentioned above, res.locals is a good (recommended) way to do this. See here for a quick tutorial on how to do this in Express.

What is the difference between setting a property on app.locals and calling app.set()?

I'm in the process of learning Express - and thinking of the best place to save config style data. Options available are either in app.locals or app.set (settings)... so:
app.locals({ config: {
name: 'My App',
domain: 'myapp.com',
viewPath: __dirname+'/views',
viewEngine: 'jade'
port: 3000
} });
app.set('view engine', app.locals.config.viewEngine || 'jade');
This would also allow me to use the following in my views:
<title>#{config.name}</title> // <title>My App</title>
Or the alternative is to use app.set like so:
app.set('name', 'My App');
app.set('domain', 'myapp.com');
... and then use this in the view:
<title>#{settings.name}</title>
I know both methods work, but I'm struggling to determine which is the better method to use. At the moment I'm leaning towards using app.locals, with the extra 'app' namespace as I believe there would be less chance of conflicts with future updates and other modules if using app.set.

Wow, all of the answers are wrong, so let me give it a try. Despite what others say assinging to the app.local argument is different from using app.set(). Watch,
app.js
app.locals.foo = 'bar';
app.set('baz', 'quz');
index.jade
block content
dl
dt app.locals.foo = 'bar';
dd \#{settings.foo} = #{settings.foo}
dd \#{foo} = #{foo}
dt app.set('baz', 'quz')
dd \#{settings.baz} = #{settings.baz}
dd \#{baz} = #{baz}
If you ran this code, what you would see is,
app.locals.foo = 'bar';
#{settings.foo} =
#{foo} = bar
app.set('baz', 'quz')
#{settings.baz} = quz
#{baz} =
The reason for this is setting app.locals sets attributes of the object that the view uses as its environment; what the view will read from without qualification. Conversely, app.set sets attributes on app.locals.settings. You can verify this if you clobber app.locals.settings in the above with app.locals.settings = {}, which will make #{settings.baz} undefined.
So which do you use? If it's not an app setting based on the response (res.set) or global configuration (app.set), use the direct write to app.locals.

All properties of app.locals are available in templates. Using app.set assigns properties to app.locals.settings, which is used for global application settings and is inherited by mounted applications. For example:
var app1 = express(),
app2 = express();
app1.set('inheritable', 'foo');
app1.locals.notInheritable = 'bar';
app1.use('/mount', app2);
app2.get('inheritable') === 'foo'; // true
app2.locals.notInheritable === 'bar'; // false
So it's really a question of preference and whether or not you're mounting applications.

The express api reference says :
By default Express exposes only a single app-level local variable,
settings.
and either way is ok:
app.locals.title = 'My App';
app.set('title', 'My App');
// use settings.title in a view

Lots of people indeed use locals instead of app.set so my advice is to use that.