4

This is probably a stupid question, but in Express, when you define local variables in res.render(view, {variable: variable}), how are they accessed on the frontend? Where are they kept? When I try to access a variable I defined through this method with console.log(variable) Firebug throws an error saying that variable is not defined. I also tried console.log(window.variable), with similar results. So where are these variables kept?

Also, are res.locals variables kept in the same place, or are they just thrown out? These variables are accessible to templating engines like swig and jade, but I could not find them using console.log() either.

trysis
  • 8,086
  • 17
  • 51
  • 80

2 Answers2

4

These variables are not passed automatically to client-side code; as you say, they're available to code in your view templates. Similarly, and variables defined in res.locals (or app.locals, which has the same API) will be available as local variables in any views.

If you want to make them available to client side code, you'd have to manually send them as part of the response, in a form accessible to the client-side JavaScript. For instance, you could write them to a <script> tag, as is done here: Accessing Express.js local variables in client side JavaScript .

Community
  • 1
  • 1
caseygrun
  • 2,019
  • 1
  • 15
  • 21
  • 1
    Darn, I was kind of hoping they put it directly in the global scope somehow, but now that I'm thinking about it, it makes sense that they need to be in a ` – trysis Oct 01 '14 at 04:37
2

These variables are used for rendering the view on the server side only. Obviously some of these values make their way into the HTML of the server side response, but you probably want to look at a module such as sharify if you want to serialize these to JSON, embed into a <script> tag in the HTML, and get access to them in the browser javascript code.

Peter Lyons
  • 142,938
  • 30
  • 279
  • 274
  • I will probably just use JSON or JSONP. `sharify` looks interesting, but it probably puts the data directly inline in a ` – trysis Oct 01 '14 at 04:32
  • Right, sharify is just for a "bootstrapping" case where you want to avoid the delay associated with an XmlHttpRequest for JSON. – Peter Lyons Oct 01 '14 at 04:35
  • Yes, that delay seems annoying. Unfortunately, it's starting to look like a choice between the delay and some worst practices like inline JavaScript. – trysis Oct 01 '14 at 04:41
  • IMHO this specific scenario bootstrapping data in a – Peter Lyons Oct 01 '14 at 04:46
  • Yes but inline JavaScript is a very bad practice. It causes blending of presentation and business logic, makes it hard to test, among other things. These don't seem so bad with a tiny app, but it's a very slippery slope to the dark side. – trysis Oct 01 '14 at 04:49
  • XmlHttpRequest loads data into your app via a second HTTP request. Inlining stuffs it in the first response. It's a good compromise for now. HTTP2 may render it obsolete but what changes is the mechanism of loading data and that does NOT a priori constitute blending of presentation logic and business logic. It's not really "javascript" logic, it's just JSON data. – Peter Lyons Oct 01 '14 at 04:53
  • As I said, it's not too bad for tiny sites, but it's a slippery slope. You really need to keep all your logics and data all separate, and in HTML the standard for that is to keep all JavaScript in files separate from any HTML and reference it in ` – trysis Oct 01 '14 at 15:25