Skip to content

Latest commit

 

History

History
189 lines (133 loc) · 9.44 KB

Views.md

File metadata and controls

189 lines (133 loc) · 9.44 KB

Views

Overview

In Sails, views are markup templates that are compiled on the server into HTML pages. In most cases, views are used as the response to an incoming HTTP request, e.g. to serve your home page.

Alternatively, a view can be compiled directly into an HTML string for use in your backend code (see sails.renderView().) For instance, you might use this approach to send HTML emails, or to build big XML strings for use with a legacy API.

Creating a view

By default, Sails is configured to use EJS (Embedded Javascript) as its view engine. The syntax for EJS is highly conventional- if you've worked with php, asp, erb, gsp, jsp, etc., you'll immediately know what you're doing.

If you prefer to use a different view engine, there are a multitude of options. Sails supports all of the view engines compatible with Express via Consolidate.

Views are defined in your app's views/ folder by default, but like all of the default paths in Sails, they are configurable. If you don't need to serve dynamic HTML pages at all (say, if you're building an API for a mobile app), you can remove the directory from your app.

Compiling a view

Anywhere you can access the res object (i.e. a controller action, custom response, or policy), you can use res.view to compile one of your views, then send the resulting HTML down to the user.

You can also hook up a view directly to a route in your routes.js file. Just indicate the relative path to the view from your app's views/ directory. For example:

{
  'get /': {
    view: 'homepage'
  },
  'get /signup': {
    view: 'signupFlow/basicInfo'
  },
  'get /signup/password': {
    view: 'signupFlow/chooseAPassword'
  },
  // and so on.
}
What about single-page apps?

If you are building a web application for the browser, part (or all) of your navigation may take place on the client; i.e. instead of the browser fetching a new HTML page each time the user navigates around, the client-side code preloads some markup templates which are then rendered in the user's browser without needing to hit the server again directly.

In this case, you have a couple of options for bootstrapping the single-page app:

  • Use a single view, e.g. views/publicSite.ejs. Advantages:
    • You can use the view engine in Sails to pass data from the server directly into the HTML that will be rendered on the client. This is an easy way to get stuff like user data to your client-side javascript, without having to send AJAX/WebSocket requests from the client.
  • Use a single HTML page in your assets folder , e.g. assets/index.html. Advantages:
    • Although you can't pass server-side data directly to the client this way, this approach allows you to further decouple the client and server-side parts of your application.
    • Anything in your assets folder can be moved to a static CDN (like Cloudfront or CloudFlare), allowing you to take advantage of that provider's geographically distributed data centers to get your content closer to your users.

Layouts

When building an app with many different pages, it can be helpful to extrapolate markup shared by several HTML files into a layout. This reduces the total amount of code in your project and helps you avoid making the same changes in multiple files down the road.

In Sails and Express, layouts are implemented by the view engines themselves. For instance, jade has its own layout system, with its own syntax.

For convenience, Sails bundles special support for layouts, but only for the default view engine, EJS. If you'd like to use layouts with a different view engine, check out that view engine's documentation to find the appropriate syntax.

Sails EJS layouts are special files in your views/ folder you can use to "wrap" or "sandwich" other views. Layouts usually contain the preamble (e.g. !DOCTYPE html<html><head>....</head><body>) and conclusion (</body></html). Then the original view file is included using <%- body %>. Layouts are never used without a view- that would be like serving someone a bread sandwich.

Layout support for your app can be configured or disabled in config/views.js, and can be overridden for a particular route or action by setting a special local called layout. By default, Sails will compile all views using the layout located at views/layout.ejs.

Locals

The variables accessible in a particular view are called locals. Locals represent server-side data that is accessible to your view-- locals are not actually included in the compiled HTML unless you explicitly reference them using special syntax provided by your view engine.

<div>Logged in as <a><%= name %></a>.</div>
Using locals in your views

The notation for accessing locals varies between view engines. In EJS, you use special template markup (e.g. <%= someValue %>) to include locals in your views.

There are three kinds of template tags in EJS:

  • <%= someValue %>
    • HTML-escapes the someValue local, and then includes it as a string.
  • <%- someRawHTML %>
    • Includes the someRawHTML local verbatim, without escaping it.
    • Be careful! This tag can make you vulnerable to XSS attacks if you don't know what you're doing.
  • <% if (!loggedIn) { %> <a>Logout</a> <% } %>
    • Runs the javascript inside the <% ... %> when the view is compiled.
    • Useful for conditionals (if/else), and looping over data (for/each).

Here's an example of a view (views/backOffice/profile.ejs) using two locals, user and corndogs:

<div>
  <h1><%= user.name %>'s first view</h1>
  <h2>My corndog collection:</h2>
  <ul>
    <% _.each(corndogs, function (corndog) { %>
    <li><%= corndog.name %></li>
    <% }) %>
  </ul>
</div>

You might have noticed another local, _. By default, Sails passes down a few locals to your views automatically, including lodash (_).

If the data you wanted to pass down to this view was completely static, you don't necessarily need a controller- you could just hard-code the view and its locals in your config/routes.js file, i.e:

  // ...
  'get /profile': {
    view: 'backOffice/profile',
    locals: {
      user: {
        name: 'Frank',
        emailAddress: '[email protected]'
      },
      corndogs: [
        { name: 'beef corndog' },
        { name: 'chicken corndog' },
        { name: 'soy corndog' }
      ]
    }
  },
  // ...

On the other hand, in the more likely scenario that this data is dynamic, we'd need to use a controller action to load it from our models, then pass it to the view using the res.view() method.

Assuming we hooked up our route to one of our controller's actions (and our models were set up), we might send down our view like this:

// in api/controllers/UserController.js...

  profile: function (req, res) {
    // ...
    return res.view('backOffice/profile', {
      user: theUser,
      corndogs: theUser.corndogCollection
    });
  },
  // ...

View Engines

The default view engine in Sails is EJS.

Swapping out the view engine

To use a different view engine, you should use npm to install it in your project, then set sails.config.views.engine (in config/views.js.)

For example, to switch to jade, run npm install jade --save-dev, then set engine: 'jade' in config/views.js.

Supported view engines
Adding new custom view engines

For instructions on adding support for a view engine not listed above, check out the consolidate project repository.