This course has been updated! We now recommend you take the Ember Octane Fundamentals course.
Transcript from the "Template Basics" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Mike: We're gonna talk about templates, so we're diving into one of these flavors of objects, and this is the first one that I'm choosing to talk to you guys about.
>> Mike: So, who's seen something like this before, right? Handlebars has been used for quite a while outside the context of Ember, and essentially what it does is it allows you to define some dynamic piece of HTML where you can insert control flow structures, and you can insert data to be populated later.
[00:00:45] Essentially, you can compile this into something, and then at runtime you can populate it with data and turn it into HTML, so Handlebars, although multiple different multiple templating engines can be used with Ember, Handlebars is what it ships with. It's the default. You can think of it as a superset of HTML, all valid HTML is also valid Handlebars, and the way to think of this is that a template is rendered in a particular context.
[00:01:24] When I say context, I mean that we have to get first name and last name from somewhere, and so we have to pass essentially some data, some object. You can think of this almost as like a closure where you have access to particular variables and a particular scope, and that is what the template uses to populate itself.
[00:01:49] When we talk about data binding, this is a big part of it, and the idea in frameworks like Ember, and Angular and React, in fact, there's an effort to basically define what we want our HTML to look like. Then, step away and basically manipulate data, manipulate objects that a template is bound to, and we expect the HTML on the screen to change, so this is an effort to take away this common problem we have of keeping HTML and our data in sync.
[00:02:26] Which, if you guys have been writing code long enough, then remember that the jQuery Widget Day is where you're finding a dime element and updating it explicitly. A lot of spaghetti code we get rid of there, so to give you an idea, I mentioned that Handlebars templates are compiled.
[00:02:47] I'm gonna show you what a compiled template looks like in a second and resist the urge to shriek out because it's a little ugly, and completely hidden from you. But, I do want to talk about this word HTMLBars, so up until Version 110 of the framework, Ember used Handlebars out-of-the-box.
[00:03:13] Essentially what Handlebars is, fancy string incantination. At that point, you set enter HTML = to something under the hood, and things get populated. This is very slow in a lot of browsers, so what HTMLBar changes is we're actually constructing dom objects. We're constructing a document fragment, which is inserted into the dom.
[00:03:39] This is a lot faster, so this is a compiled template, and I'm gonna zoom in here, and we can see that, if we go back, just looking at Hello Karma, it's wrong. We can see that those are, that's the beginning of our string here, right? But all we're doing is using the down api here and construct the elements and ultimately.
[00:04:11] Building little hierarchy, and then inserting them. So, what I want you guys to understand is that this is done at build time. You're translating your HTML+ syntax Into a JavaScript module like this at build time. So all we have to do at run time is evaluate this. And there are potentially huge performance gains that we can see in the future because here we have knowledge of exactly what piece of a template has to change.
[00:04:48] Because it's connected to this variable. We at build time have that information about what things potentially could change as the result of which data changing. Which potentially could give us a lot of. It could make things even faster than React. Which My understanding is they are forced to re-render something entirely because at build time they don't necessarily know exactly what html could change as a result of a particular piece of data changing.
[00:05:24]
>> Mike: So, I mentioned this concept of handlebars helpers. Here's an example of one. It's a simple conditional here and you can, I mean it's pretty self explanatory here. If used in line the first parameter is some boolean value and then we have it something to spit out if it's true and something to spit out if it's false.
[00:05:48] You can also use block form, block syntax, which is starting with a hashtag and then closing with the slash. And so, on the lower left here you can see you can make an if-else in a way that is pretty easy to read and pretty similar to the way we structure A JavaScript control flow of the same thing.
[00:06:15] There's also unless, which is just the inverse.
>> Mike: An important thing to note is that, you may be asking yourself why don't we just say, if not is dog? There's a limited amount of logic that you can put into the handlebars files themselves. And in this case, we can't really evaluate arithmetic or logical statements.
[00:06:43] So in this case, unless is the way to go. Rather than trying to make a not operator of some kind. When you start writing your own handlebars helpers, that is where you can start customizing the expressive language you can use in a template. So here's an example of iteration, and we're gonna use this when we start coding.
[00:07:04] This is a very very very common handlebars helper to use On the top we're iterating over a list, and we just say each and then the name of the list property itself, and then we get a local variable that we can use within the body of each. So you can see we're gonna print out my list item You know, in an LI element iterating over.
[00:07:35] Also this is an often overlooked feature of each. It gives you the ability to use else to have some template for the empty case where there's nothing in the list.
>> Speaker 2: People are asking about SEO and if there's a decent story about number 2 and pre rendering.
>> Mike: SEO is less of a problem than most people think, and this is because Google's Crawler now executes JavaScript.
[00:08:13] There was an SEO problem with single page apps before this. And when we fire up our app, when we get started you'll see that the index.HTML we start with is basically empty. And if you don't run JavaScript that's what you're going to see. And that sucks for SEM Now, single page apps will get picked up.
[00:08:35] In addition to that, there's this concept of server-side rendering. Which essentially is running Ember in a node.js server. And spitting out the initial view. Instead of starting with an empty template, you start out with Some meaningful state and then when the client downloads the JavaScript and interprets it and starts it up.
[00:09:00] Then you have the single page app functioning. So there are two solutions to that but I guess the short answer to that is because Google runs JavaScript, single page apps get picked up just fine.
>> Mike: Just to give you guys a little check as to where we're going with this, I'm going to talk about the router.
[00:09:27] This is the last thing I'm going to cover, and then we're gonna actually start coding. My hope is about 20 more minutes, and then we're going to dive in.
>> Speaker 2: Here's a question on iteration.
>> Mike: Okay, lets go back to iteration.
>> Speaker 2: They're asking, does having a key on each iterator make it faster to update the iterators?
[00:09:52] For instance, react needs key, angular Is benefited from track by.
>> Mike: I'm not sure what a key means in this context. So you can iterate over a primitive array, not necessarily an array of objects. In which case what I assume they mean by key has no meaning. I do see a question online so, why build with Ember if you can build with Ruby on Rails?
[00:10:45] With a single page app, you have to think of your app as being a completely separate system component. There are advantages to being able to deploy your UI independent of your API. Deploying an API is quite frankly a pain, compared to building and making available a new set of static assets.
[00:11:08] That's what we ultimately ship with a single page app Piece of Job Script. Piece of CSS. A little HTML. My advice for building, which we will get into tomorrow, is treat this as a separate app. Were building against the Get Hub API today. This is going to be a completely separate application.
[00:11:29] There’s no reason to couple things together if you can get away with separating them.