wycats / handlebars-site

56 stars 66 forks source link

Triple bracket notation confusion #196

Closed DapperDataDog closed 4 years ago

DapperDataDog commented 6 years ago

I am trying to get a better understanding of how Handlebars works before embarking on using it as a tool myself.

So I set up my sandbox with the express CLI specifying handlebars as my view engine ( express --view=hbs sandbox ) and it generated the appropriate file structure.

After I installed and I started the generic app as-is and navigate to localhost:3000/ I am provided with the expected Express page.

It is to my understanding that by navigating to '/' I am triggering a router referenced in './app' and is ultimately found in './routes/index.js'

...
var indexRouter = require('./routes/index');
...
app.use('/', indexRouter);

If I look at that route I see that it references "index" as its view and passes variables along with it to said view.

router.get('/', function(req, res, next) {
  res.render('index', { title: 'Express' });
});

When I go to the view of './views/index.hbs' I see that the passed information is consumed in an h1 and p tag.

<h1>{{title}}</h1>
<p>Welcome to {{title}}</p>

If I go to './views/layout.hbs' and make modifications there they are expressed when I visit 'index'.

<!DOCTYPE html>
<html>
  <head>
    <title>{{title}}</title>
    <link rel='stylesheet' href='/stylesheets/style.css' />
  </head>
  <body>
    <h1>Just Checking!</h1>
    {{{body}}}
  </body>
</html>

There is no reference to 'layout.hbs' in either the route or view of 'index'.

When I try to find what the view engine is doing I can only really try and research the fact that it is a handlebars element with three brackets instead of two which has repeatedly yielded the simple explanation of "Unescaped Element"(Example : https://mustache.github.io/mustache.5.html)

How is layout.hbs influencing index.hbs?

This isn't an issue of functionality so much as an issue of documentation so the end result can be effectively replicated and explained.

Additional research :

It appears a similar question has been asked ( https://stackoverflow.com/questions/31496731/what-does-variable-mean-in-handlebars ) and the answer is what I have found as well but it does not explain {{{body}}} and how it is taking in the index information.

Themayu commented 6 years ago

I believe that the hbs module (which is simply a view engine to wrap Handlebars.js itself) will load the given "layout" file alongside the view file itself. It will then assign the "body" variable's value in the layout's context to be the constructed view, and then process the layout itself as if it were a normal template, inserting the value of "body" where it is referenced as it would for any other variable. The triple stash {{{ is part of Handlebars.js, and is to signify that Handlebars should not escape the value of that variable prior to inserting it into the template.

This is simply my interpretation, though, so I could be wrong.

As for ./views/layout.hbs, that is simply the default path that the hbs module uses to locate the layout file.

DapperDataDog commented 6 years ago

I believe that the hbs module (which is simply a view engine to wrap Handlebars.js itself) will load the given "layout" file alongside the view file itself. It will then assign the "body" variable's value in the layout's context to be the constructed view, and then process the layout itself as if it were a normal template, inserting the value of "body" where it is referenced as it would for any other variable. The triple stash {{{ is part of Handlebars.js, and is to signify that Handlebars should not escape the value of that variable prior to inserting it into the template.

This is simply my interpretation, though, so I could be wrong.

As for ./views/layout.hbs, that is simply the default path that the hbs module uses to locate the layout file.

@Themayu , I do believe you're right! I was so focused in on Handlebars that I forgot to consider the fact that Express may be manipulating how Handlebars is functioning.

You're explanation makes sense to me given what I described and so far I've not found any test cases that refute what you're suggesting.

You're great, thank you very much for taking the time to reply!