Can someone explain View.js to me?

[Ryan Cole]

There is a lot of really cool looking stuff in this class, but I can't quite wrap my head around what each part of this pipeline thing is for.

this.initQueue = [];

this.actionQueue = [];

this.queryQueue = [];

this.renderQueue = [];

Theres the init array which is stuff to do in the beginning synchronously, then actions, then query, then render.

What I'm hung up on is what types of things go in init, and action. I feel like this is really the guts of the CMS and I end up not using it because I don't really know when to use it. 

Also I'm really frequently building a REST API rather than traditional views, so can I still use it to render a json response?

I feel like once this class, and updateHandler have more documentation the whole CMS will be a lot more attractive to more users. 

[Jed Watson]

Hi Ryan,

You're right - these are badly in need of documentation. Hopefully we'll fill that gap soon.

You can really put anything you like in those stages - it's basically async sugar for rendering views, with some built in cleverness for querying data and handling different HTTP methods conditionally.

So init is for anything you need in every case, e.g.

view.on('init', function(next) { /* do something async and required regardless of actions */ })

Actions are shortcut methods for handling events like form posts, optionally with body values that are checked (e.g. if you have two forms on a page, include an action hidden input in each with different values)

view.on('post', { action: 'submit-form' }, function(next) { /* handle the form submission */ })

There's sugar for executing queries, which happen after actions (since you may change data with an action that would affect the query return)

view.query('key', SomeList.model.find().where('condition').eq('value'))

is basically equivalent to:

view.on('render', function(next) {
  SomeList.model.find().where('condition').eq('value').exec(function(err, results) {
    locals.key = results || [];
    next(err);
  });
});

... and the render queue happens last before the view is rendered.

Speaking of which, yes - you can pass the render method a function (to respond with JSON from an API) which will be executed finally, instead of the name of a template. So yes it works well for REST APIs.

view.render(function(err) {
  if (err) return res.send({ err: err });
  res.send({ results: locals.key }); // see above :)
});

[Ryan Cole]

Ah ok it's clicking into place. I think was was strange for me was that you would have the different http verb actions splitting at this point rather than in the actual routing file. 

I guess it does make sense though in the context of rendering views. I'm just coming from the SPA world where everything is done over rest so I'm not even used to thinking about all the data that goes into building a single view haha. 

It's quite a different way of thinking I suppose. 

With a rest API an action and a query would essentially be the same thing. A record would get updated and then return the new record which would then replace the current one in the UI. 

Cheers!