 Hey everyone, it's Sam here. So you might have watched a few episodes so far and learned a little bit about the different parts of Santa Tracker and how it works. But what I want to do today is talk about how you actually build it yourself and how you can, you know, quite literally check out the source code and run your own version. So to start with, let's have a look at our command line. We've already checked out Santa Tracker, you know, we've gone to GitHub and got the repo and let's look at what we do now. Start by checking it out. You can have a look, we've got some content here. It's got a bunch of stuff. But what you can start with is by basically running yarn install. And so yarn's a package manager, you can fetch that with Homebrew or some equivalent on your machine and it will then go and do a bunch of stuff. In our case, you can see here, it's pretty fast because I've actually checked it out before and so it'll go and fetch all its dependencies and things like that. What it's actually doing is it's internally calling Bower which is a package management tool. It's a little bit older. It's still needed for Polymer 2. I know Polymer 3 is upgrading to MPM and that repository, but for now we still need to have Bower installed to check out all the code. We then run our build tool which is using the gulp build system. So the default task that we have in gulp will build Santa Tracker and I'll actually let us serve that folder. So if I just run serve here and hit enter and then load it up and load this URL, we'll see that take a few seconds to load and Santa Tracker will load up with all its fun, exciting stuff going on. This version will be a little bit slower than the production version for a bunch of reasons which I'll kind of cover in a few seconds. So because we're developers and we've got access to Santa's Village whenever we like, you can actually go and click on these scenes to see what's going on. So we can cut Santa's beard and things like that. One thing to think about is that these scenes will load dynamically. So if we load the dev tools, firstly we'll see our lovely responsive design but if we go to network here and set the speed to say fast 3G, we can see the loading happen. So we actually loaded the Santa selfie scene so that'll load really fast but let's go to a scene we haven't loaded yet. So this might be the gift slingshot and I love this scene, which I call boatload. That's its actual ID because it's actually pretty small. It's not too complicated. Yet it does most of the things that a regular Santa scene will do. And we've got, you know, every house in the Village, these cards is what we call a scene. So let's click on that now. What you can notice is that we've actually got the red bar at the top here and that slowly moves across the screen as all the resources that are on the right here are loaded into the page. And this is a pretty small scene so it loads pretty fast. Even on a slow connection. We can also play this game. So how do we get to these scenes? If we go to the code and look at Santa app.html, this is a Polymer element and we've had another episode in Polymer so I won't cover this extensively. In the middle here is what we call the lazy pages element. And this element is entirely designed to load these pages at runtime. So interestingly enough, these scenes aren't on the page when you load Santa Tracker. These are essentially unknown HTML elements that your browser doesn't know how to render. What lazy pages does is that when the route changes to that URL, when we want to load the boatload scene, for instance, it then goes and finds, okay, here's the boatload scene. It goes cool. The path is this HTML path, including a language field. It then loads that into the page and when that's loaded, we can then show that scene because all the resources to do with that element are now on the page. So if you notice, we've got it open as well. So a couple of things to note here. So firstly is that we bring in the JavaScript for the scene. So when you first build and check out Santa Tracker, your build might still be running because we actually compile every scene's JavaScript with Closure Compiler. The reason we do this is actually because a lot of the scenes are quite old. They typically predate the majority of scenes predate Polymer. And there's a few scenes which are very modern and they're built a little bit differently, but most of our games are written fairly generically. They don't really care about Polymer. And actually there's kind of a nice strength of Polymer in that we kind of wrap up the HTML and JavaScript in a very neat way just within this one file. So this scene has made up of a bunch of things. It's got a template, which includes the kind of inbuilt style we care about. It also has a bunch of divs and elements like trees and elves and stuff. Like this is the cute things you see around this, the slingshot scene. A bit down, a bit further below, we've got a very interesting message here. This is an I18N message. In production, we actually remove this div completely. We swap it out for the message that's appropriate for your language. But in Dev it lives here so we can quickly switch languages. You can actually see this if we go to the site and we go to console and type document.documentElement.lang equals let's say German. And a few seconds later, we see all the language stuff changes. And the way we do that is with that element. But in production, we've actually got rid of that element completely. If you're curious about how we do that, you can actually load up the gulp scripts, the replace script here. And so if you have a look around, what we do is we actually load each page into memory, which is this mutate function here. And we do regular query selectors. We say, so for everything with a message ID or everything with a of this tag name, okay, this actually is the wrong, oh, I see, because each message has that message ID. So we catch it here first. We'll actually replace the content of that message ID for that language. So that's kind of cool. That's part of our build processes as well. And so finally, let's talk a little bit about gulp. So I mentioned earlier that we use gulp to build stuff. We can also use gulp to serve things. So if we type gulp serve here, we'll actually see it'll do the same thing. It'll do this default compile step, which yet again is happening pretty fast for me. And then we'll actually run a web server. So this is the kind of the best way to run it and test center tracking yourself. And this serve command as well will also do auto reloading. So if I change something, let's say I change this boatload scene to have some text just somewhere. Hello. Then what you'll see is this page will automatically reload. And actually, you won't even on that scene. But if we load it up, you can sort of see that text now appearing there. Oh, there we go. Very subtly in the corner, there's a hello. So hopefully you've learned a little bit about the way you can build and test Santa Tracker even on your own machine. So Santa Tracker is a big complicated single page application. It really has one entry point. And then it loads these individual scenes as we need them, which is super interesting in itself. If you want to learn a little bit more about that and also build instructions of how to run and build Santa Tracker, there's some links below. The article I'm linking to is an article I wrote last year which talks about how Santa Tracker was made into a progressive web app. And while of course that's a little bit of a different topic, it actually covers a little bit about loading. And this is important because as a PWA, we care about offline and caching. And so one thing we do that's interesting is that we only cache scenes users have been to before. And that matches the way we load scenes only as users need them rather than loading the whole site at once. So thanks for watching and I'll see you next time. Thanks for watching. You can subscribe to the Google Chrome developer channel down here. Or check out some other great videos along here.