 I'm Adam. I work at a little company called Ten Up. I'll give you my bio at the end. But I'm going to jump right into this with a little story that I like to tell. I have a lot of stories. Oops, I went ahead. So the story is, decades ago I was in Kathmandu, Nepal. I was heading out to trek in the Himalayas and I was sitting in a cafe. It was a German bakery cafe in Kathmandu and I was writing in my journal looking at notes and lonely planet trying to figure out where I was going to go. Beautiful day. A lot of people in the courier are very interesting. Suddenly an object fell from the sky, bounced on the ground next to me, bounced up and landed on my plate. And it was a grapefruit. And I looked around and no one else had noticed this happen. I was the only person who had seen this so I ate it. So Backbone is your grapefruit. It's an awesome technology for building front end solutions and I'm going to talk a little bit today about how awesome it is and how you can integrate it with WordPress and how WordPress helps you use it. And we're going to dive into some code samples towards the end. So this is from the Backbone website and it kind of describes the philosophy of Backbone which is similar to other JavaScript frameworks that allow you to build applications but is specifically designed to be the most minimal set of tools that you need to build an application. So what that means is that there's a lot of things that it doesn't provide that you have to build yourself. It also means that it's incredibly flexible. You can use it in many different ways. You're not tied to a specific set of usage requirements. And it's modular so you can take pieces of it and use those pieces and not use the other pieces. So this is basically my main point to you is Backbone is awesome and I'm going to illustrate that by talking about why you would use it and also show you some examples of uses of it. So first of all when you use Backbone you're going to wind up with an awesome experience for your users. You're going to create a very fast fluid experience because they're going to be working right in the browser. Everything's running in JavaScript. You don't have that back and forth that we're used to in traditional web applications where you click a button. It sends a request off to the server and then you wait and then the page refreshes and you have your new information. With a Backbone application it's a much more fluid experience and you're going to get a really great experience for your users. It's also going to help you organize your JavaScript code. If you've ever built something in JavaScript that was more than a simple interaction you start to have more and more code and it becomes spaghetti code. It becomes very difficult for other developers to figure out what your code is doing especially given that JavaScript is kind of asynchronous in nature. There's things that are happening. Other things are happening. You're waiting for something to come back. Maybe several requests are going out at once. By using Backbone you sort of are forced into a basic structure for your application. We're going to talk about that in a second but it winds up being super useful when you have larger projects or you're working in a team where you have multiple people working on the same project. The third thing what I already mentioned is a very lightweight library and it's designed to be extended. It's designed to build on top of. I prepared this very easy chart for you to follow to determine if you should use Backbone on your next project. It's like my one joke in the whole talk. So some examples. Backbone is widely used but you will find a great list of examples on the Backbone.js website. By the way this site is the place to start if you want to learn about Backbone. There will be some links and resources at the end. I just visited this site again recently and then they have a whole new expanded kind of intro to Backbone section. The first kind of 10 paragraphs are going to cover all the stuff I'm covering in this talk and go in more depth. Awesome annotated source code as well where you can read every line of the Backbone source code and it explains what it's doing in that section of the code. So it's a really easy to jump into kind of framework. There are a lot of major sites that use Backbone. Backbone is used extensively in WordPress core. There's also quite a few plugins including Jetpack that use Backbone to build their interfaces and applications that you probably have used before like I use Basecamp every day. Probably you've used some of these other web applications. These are things that are running your browser. They're completely JavaScript driven. There's some sort of back end component but the application that you're interacting with is a Backbone application that's running in your web browser. Feel free to interrupt me if you have questions because I have plenty of time. And Backbone is used extensively in WordPress core. More and more parts of WordPress core are moving into Backbone because it creates this awesome experience for users. So I created this little video where we can sort of watch some of the... Okay, I'm going to hit the button one more time and hopefully it's going to start. Oh, there it is. Okay, great. Some of the things we've done in core. So I work in core a lot and these are the kinds of experiences that we're creating with Backbone. So you've probably used dropped a bunch of files into the media uploader. Maybe some of you remember what the media library was like before we had this. But you certainly weren't doing things like I'm doing here. My file is uploaded instantly because it was local but if they were still uploading I could be doing this editing of the meta information like the captions and so forth while they're uploading. It's super great experience to use compared to what we had before it's night and day. Revisions. I worked on this extensively for like half a year and we turned the old interface which was you click two radio buttons and you click compare revisions and it sent off a request to the server and then it gave you this nice diff view and then you try two other revisions and do it again until you found what you were looking for. Now you've got this great slider. You drag it back and forth. You can find... You instantly see the preview of your revisions. You do diff and you can even compare two revisions and it's a much more fluid experience. Again, if you've used it before it's the same exact functionality. You're doing the same thing but the interface is completely different. Themes. This came up probably in the last year. We rebuilt the interface for searching for themes in core. So if you've used this where you go in you add a new theme and you've got this nice preview. You can hit next and back and go through the themes that you've got installed. You can search the repository. All this stuff is done in backbone. And it's so nice. You get these great previews. The next and back. It's also accessible which is important. And compared to what we had before, again, you might not remember but it was this a lot slower of an experience. You had to sort of click and then you'd wait and then you'd see the new theme and maybe try this one. Now you've got this kind of instant response because it's all sort of happening in your browser. There is still some request going back to the server but they're sort of invisible to the user. The media library with the grid view that we created and now you can just navigate right through all your media. Remember before we just had a list of media. And then you had to click on one and you go in and you could edit it now. You're actually able to see them all in a grid and you can edit them in this nice dialogue that comes up where you can pop through. You can drop into the edit mode. All the stuff that you're used to doing in images but now in this very sort of fluid backbone-based interface. If you ever want to extend or interact with these parts of core, you're going to have to learn some backbone. So it's a good motivation for increasing your knowledge. These things are a little complicated when you first dive into them because they are really huge applications so maybe not a good starting place to learn about backbone. There's some demo projects that I'm going to give there on my GitHub that you can look at that are very simple. But this is the type of experience that you can create when you start using backbone. And I've used backbone to build some pretty small stuff. We built a search feature recently that was pretty sophisticated for a search feature but it involved getting data from multiple sources. It involved the ability to navigate with the keyboard. Thank you. And it was an awesome experience. Worked with multiple people in a team. Some people working on the front end part. Some people working on the back end. Some are working on accessibility. Everyone sort of knew where to go in the code to make their changes because of the structure that backbone gave us. So now I'm going to jump into the structure. Any questions so far? Nope. Okay. I'm going to jump into the kind of basics of backbone. Give you kind of the fundamental understanding of how we build stuff in backbone. So the most basic thing are the models. And these are the containers for the data of your application. You can think of these as like a row in your database. So a model would contain all of the data about a specific record or element. And models generally would also possibly contain business logic about how that data would be handled. But that's all they do. They're containers for data. I don't know why collections is next. I'm going to go back to that one. Views are supposed to be the next one. So views are what we use to both render into the DOM, the data in our models, into the browser. That's the DOM. And also we take events back from the browser. All of that is handled inside the views. So the views are responsible for the rendering and all interactions that are coming from the browser. Generally speaking, underlying each view is a model. And we're going to get to some very detailed examples of that so that you can understand it. The one that was supposed to be after that is collections. And collections are groups of models. So you can think of a collection as your entire database. It's a bunch of rows in a database. It's a bunch of models all in a collection. And what the collections allow you to do is the same kinds of things that you can do on arrays that you're used to doing. You can filter them. You can search through them. You can grab certain elements out of them. I should say that both models and collections also have a sync method that allows them to both pull data from JSON API or send data back to the server. So an individual model can get its data directly from the server. So can a collection, a whole group of models that can make a single request to the server. That server responds with the data. And that gets populated all into the models that are in that collection. So a couple more things that are built into Backbone and that you will use a lot. The templating library is based on the underscores library, the mustache templating. And in WordPress, we often use a helper function called WPTemplate that is an extension of the underscores templating that basically just uses some different tags and also kind of matches better what we do in other parts of core. But other than that, it's pretty much just a thin wrapper around underscores templating. And what the templating does is it takes the data in your model and it puts that into an HTML template that you create that has placeholders for the data points. And we're going to see an example of that. Events are available for views, for example. So you can attach events to views. So you can handle events like click or input or whatever events that you're used to handling in jQuery. It's the same type of events. But you're going to put them on top of one of these objects like a view. Routes are used to take the URL that you have in your browser, the address in your browser, and transfer that into a state in your application. So backbone applications are generally stateful, meaning you can drill down into the application. Maybe you've got a view of a bunch of records and then you click on a record and it takes you into the detail view of that record. That's the state of the application and you're viewing that detail view. If you have that reflected up in your browser bar and you read the page and it goes back to that same state, that's what the router is doing for you. It's taking the URL that's passed to the browser and then it's processing that into a function that's going to place your application in a certain state. And I will show an example of that as well. And then history is basically allows you to interact with the history object, the browser bar, so you can provide features like being able to hit the back button and go back through different states in your application. So this is like if you've used any one of those applications and you notice you hit your back button, it doesn't take you back to the previous webpage, but it takes you back to sort of where you were in the application right before you did whatever you just did. Any questions? All right, everyone understands all this perfectly. So data, how do we get data into our applications? Basically two primary methods, bootstrapping and fetching. So bootstrapping is when the PHP page renders, we take all the data that we need from WordPress, maybe all the post information, we localize that information so that it's available for the JavaScript application and basically when the page loads, that information is already available. If you're not familiar with localizing data, we use a function called wp localize script and basically that will take a PHP variable or object or whatever and it will turn it into a JavaScript object that gets basically rendered right before your JavaScript gets enqueued. So this allows you to take a bunch of data that you can query in PHP and have it available for your JavaScript application as soon as the page loads. Once the application loads, you can send or receive data using a fetch or sync method in backbone. So typically what we would do is at page load we would try to load just the minimal amount of information that's required for the application to start up and then once it started you would make a request back to the server to get whatever other information you might need or as the user started interacting you might make those additional requests. So an example of this is in the revisions interface. Let's say you have a post and it has 10 revisions. When you first load the revision screen, the bootstrap data basically is the list of the revisions and the information about each one, like this revision was made on this date by this user. That's all that it needs and it needs the first diff, the one that you're viewing, but it doesn't need to load the rest of them because you can't see them when the application loads. Once the page loads, it fires off an Ajax request back to the server and what it gets back is all the rest of the diffs that you could possibly see by sliding your slider. So the effect of this, of separating the data into a bootstrap and a fetch call is that the application loads more quickly because you don't have to load all the data that you're potentially going to use when you first load the application. All right, a couple more kind of helpers that we use in WordPress. I mentioned WP localized script. This is kind of the go-to tool that we use to get data from PHP to JavaScript. It was originally for translations because we don't really have translations in JavaScript in WordPress, so that's why it's called localized, but it's been widely extended to be used for any data that you want to get from PHP to JavaScript. The WPJSON rest API, I think maybe it's now just the WP rest API, but this is the thing we're all waiting to get into core, but it is available in a plugin now, so version two is in the repository. What this does is it provides a JSON interface to the data that you have in WordPress. JSON is a data format, so that's the, you know, you've all seen the JSON data. That's the data that Backbone wants. Backbone basically is designed to ingest JSON, and the rest API spits out JSON, so they are match made in heaven. You can get your data also using the standard WP-AJAX callbacks, that if you've ever built anything that uses AJAX in WordPress, you're familiar with these callbacks. You can set up an AJAX endpoint basically that calls a function on your server, and your PHP code would generate the data and generate the JSON file sort of manually, I guess. I would say at this point I would start just using the rest API and not use WP-AJAX unless you're trying to manipulate something that's for some reason not accessible to the rest API. Maybe if you're doing authentication, WP-AJAX might be easier. Nonsense is a security feature that we use whenever we're interacting with the server. It's a number used only once. The idea is that you are verifying that the user has the intent that the AJAX request is indicating, and the way that this works is when the page loads, the PHP generates the nonce, and when the request comes back, it's expecting that same value. It prevents the kind of man-in-the-middle attack or where someone clicks Jaxu, they cause you to make a click, but if you don't have that original nonce value, it will fail. For all types of requests that we make back to the server, we always use nonces. A couple other really useful functions, the remote API, or this is actually a whole class of functions, but the remote API allows you to, in PHP, make requests out to remote APIs. This would be typically used if you're building something in Backbone, there's a limitation with JavaScript in that you typically can't connect to remote servers using JavaScript. You can't just, you can load a script from a remote server, but once you've loaded a script, you can't just connect to some other server. If you want to pull something safe from the Twitter API, you actually have to make your call back to WordPress, to your main server where the, where your page loaded from, and then WordPress uses the remote API to go out and fetch that information and then return it back to your application. That sort of prevents that cross browser, cross domain problem that you run into. And of course, if you're going to be going out to remote APIs and fetching them, you are going to want to cache that data so that you don't have to do it every time someone makes a request. That's where the transient API comes in. That's the kind of caching API that we use. There's also WP cache. Some other helper functions. WP send JSON takes data they have in PHP and just formats it as JSON or also provides a little bit of helper around providing the right headers and kind of a fail success. And I mentioned WP template. WP Backbone View is a special view that has been built on top of the normal Backbone View object that supports subviews. So this is really handy when you have like one large view and then a bunch of views that are under it. And you want to have sort of a rendering chain when, when things down below change and things up above need to change. A good example, this is the media library. That was what that was originally built for. So you've got sort of the master view of all the items. And then each one of those items is its own view. So subviews allow you to kind of connect to those two together. It's not built into Backbone, but WordPress has extended it to allow you to do that. And if you want to learn more about the WP Backbone View object, I highly recommend Mark Jakewithstock from WordCamp San Francisco last year. It's up on WordCamp TV. It's entirely focused on this object. And he goes into great detail. And there's also a project up on his GitHub where you can see how it's used. Underscore. So underscore is a dependency of Backbone and it's a JavaScript library written by the same guy. It is a class of functions that will help you writing JavaScript whether you're using Backbone or not using Backbone. It's got just awesome helper functions for things that you do all the time and you maybe didn't know that these things existed. So it's got these great collection functions. Again, these, for example, function on Backbone Collections, but you could do them on any collection. It could be a JavaScript array. Pluck is fun. It's like WP ListPluck. It'll pull one value out of an array. Filter is a really nice function if you're familiar with PHP array filter where you can have a callback function and filter the items by some logic check. Great functions around timing. This is a big issue in JavaScript when you start having things that are happening multiple times or you're reacting to, say, user input where they're typing into a search box or they're dragging their mouse over something. You run into kind of some issues. So some of my favorite functions are throttle and debounce. They're a little bit different, but what they do is throttle will keep an event from, it'll basically set the timing of an event to a specific interval. So if you throttle an event, let's say a good one would be like a mouse drag event. Someone's dragging something and you're following that. If you just call that event, let the browser call back your function, you will get so many callbacks that your browser will start to freeze because it's happening like 100 times a second. What throttle will do is it will keep those calls coming at a steady rate, say every 250 milliseconds. So you can throttle any function basically and it will only be executed every x number of milliseconds, whatever you pass to it. Another great one is debounce and this is similar to throttle except that it only fires the function once at the end of a sequence of events that happen more quickly than your interval. So I like to use this for searching. So if you're say typing in a search box and you want to have that instant search result thing, you don't necessarily want to fire off a request every time someone types a single character. So if you debounce that callback to say 250 milliseconds, what that will do is they can type away and as soon as they pause for 250 milliseconds a quarter second, then the request gets fired off. So it's a great way to sort of take an event that you only want to have happen at the end of a series of events and it will fire then. There's also once, which is really handy when you have a callback that you only want to have happen once. Memoize is a caching function. So if you have a JavaScript function that's relatively complex and it's taking time to execute, you can wrap it in Memoize and it will basically cache the results. So for whatever value is passed to it, it will cache the generated value and the next time you call that function with the same arguments, it will just return the information from the cache. These functions are all in underscore, so you don't actually have to use Backbone to use these functions. So if you're writing JavaScript, start by looking at underscore. Yes. So these are just utility functions, defaults, extend is a great way to extend options in an object. You'll have to go to the underscore site. Again, great documentation on there to kind of dive into the details of how you would use these. There it is, underscore.js.org. All right. I did have a couple of examples for the underscore stuff. So this is the filter, right? So here's what I've got a group of people in a collection. This is a collection object here. I'm taking all those models and I'm going to filter them by basically calling this callback function on each model and I'm checking to see if the title index of search is not equal to negative one, basically is the search inside that string and if it is, the model will be included in the resulting collection and if it isn't, the model won't be included. So what this does, again, it's going to filter through all these models and for each one it's going to search through to see if the search is in the title and those that meet that criteria will be included in the results. Here's the debounce. So this is again, you're typing and instead of calling the original trigger search function, we're just going to call the debounce trigger search, which all that does is it's only going to call the trigger search after the events stop firing for at least a quarter second. Yeah, throttle. So this is actually the throttle example and this is where you would fire the events continuously every quarter second. That would probably be better to do a drag there. All right, coding in backbone is fun. I just like roller coasters, so I put that up there. It's mostly fun because you create awesome results, but it's also fun because it's got great documentation. If you've ever worked with an API that has lousy documentation, you will really appreciate how good the documentation in backbone is. Great examples. Just the site itself has all the information you really need to get started. It's actually pretty easy to get started in backbone. I think when you're first starting, it seems like a lot of code to write for maybe something small that you're doing, but once you start using it, you realize that you can take, say, the back object and if you're just creating a small thing that's going to manipulate some data in the DOM, you can actually just use backbone view and you sort of benefit from the structure that's behind it and the sort of built-in things that it does like fire certain events automatically. It's very straightforward to understand. It's extendable, meaning that you can add on to it every which way. It doesn't really dictate how you do things, so there's a lot of choices how you put things together, especially when you get into a larger application. That's kind of a plus and a minus. Some people don't like that about backbone because it doesn't really provide all the tools you need. It just provides the minimal set and then you sort of are forced to build on top of that to make it do what you want to do. There isn't really a right or a wrong way, so you have to kind of invent it. That's one nice thing about working in core is that you at least learn sort of the WordPress way. I mentioned this already, but the code structure that it creates is great for collaboration because you have this separation of interest because you have your data and your models, you're rendering in your views, you've got your HTML in your templates. It allows multiple people to work on the project at once without all committing to the same file. The templates and the data binding, this is sort of one way data binding, but this is basically where we're taking data from our models and it's getting rendered with templates onto the DOM. This turns out to be incredibly powerful. If you've ever tried to write HTML into the DOM, you wind up with a lot of messy stuff. You wind up with a lot of HTML inside your JavaScript and then if you're trying to say debug an issue, it can be very difficult to figure out where something is coming from. When you have templates for your HTML, you know where your HTML is. The separation that you have there, it becomes incredibly useful when you're doing things that are more complicated. A couple challenges that we face with Backbone, internationalization and localization, this is basically the idea of being able to translate your strings. You can't do that in JavaScript right now in core, so what we're forced to do is do all of our translations in PHP. Any string that you want to have, like a thing that pops up and says saved or whatever, that word saved, if you want people to be able to translate that into different languages with the typical WordPress translation functionality, you have to do that in PHP, then pass that through to the JavaScript. So it kind of creates a little burden, a little extra step. If you're building, if the strings are in your templates, it's a little bit easier because you can just drop them right in the templates because those are in PHP. Accessibility is an issue with any application, but especially with Ajax-y Backbone applications. There's a lot of stuff happening on the screen that if, for example, you're using a screen reader, you have no way of knowing it's happening. So if you're making an Ajax request and something gets updated, a screen reader can't recognize that change. You have to inform the screen reader that something has changed. So we have a great new function inside WordPress Core called WPSpeak, and this is a really simple JavaScript function. You can just pass it a string and it will speak it. So let's say you click on a button and it sends a request and then you have a little thing that pops up that says saved, right? Then you can have WordPress say item saved or whatever you want to inform a screen reader of. There's other accessibility issues, but I would say the biggest one is the fact that it's unlike a traditional application, it doesn't have the same like elements that respond and load, so it confuses screen readers. Screen readers have a hard time following what's happening inside a JavaScript application. If you want to test this, just fire up the screen reader on your Mac or you can download a Chrome extension to do it and try closing your eyes and using your application. It's a fun experience. No JavaScript, no JS. This is an especially big concern in core where we have however many hundreds of millions of people using the application. Some people don't have JavaScript enabled in their browser. Maybe they've turned it off because they don't want to get ads or maybe they have an old phone that doesn't support JavaScript or maybe their corporate policy forces them to have JavaScript disabled. So what's going to happen with your back bone application? It is not going to work. It's entirely in JavaScript. So you need to think about are you going to provide a fallback. With core, mostly what we've done is we've kept around the old functionality, so that still works because it was already there. But it's definitely something you have to think about. If you're providing a critical function on your website, you have to provide some kind of fallback for how people are going to use that in a browser that doesn't have JavaScript. It doesn't have to be as fancy as the JavaScript version, but you need to think about at least some base functionality. All right. I think I'm getting into demos. Any questions before I go on? And we're going to look at some code. Yes. Yes, exactly. Both back bone and underscore are now included in core. So that's one of the main reasons why you might choose to use back bone on a WordPress project is it's already bundled in core. You don't have to worry about bundling your own library. You just add back bone or underscore into the WP and QScript, and it will be there. Any other questions? Yeah. That's a strategy. That's sort of the strategy we've taken in core. Like, okay, you can't use the media grid, but we still have that list view you could always use. So sometimes it's like, okay, revisions, that's not really a critical function. Like you don't have to have revisions to use WordPress. So okay, it doesn't work if there's no JavaScript. Sometimes people actually go much further and they do, you can take your templates that you've developed for JavaScript and you can actually use PHP to render them. So you can kind of redo your application in PHP but without the fancier interactivity. That has its own set of problems, and I've never tried to do that, so I can't really speak to it. But I know people do try to do that. They try to kind of use PHP to ingest their templates and put the data in there and do sort of what back bone is doing. So this is the first demo. It's going to be very, very simple. All I'm going to do is display a single post. We are going to use the view model and the WP template to render, and we're going to pull the post data from the REST API. So if you go to my GitHub later and you install my demos, they're a little hard to use, but you have to install the REST API plugin to get them to work. Mostly I put them up so you can look at the code after the session and kind of really dig into it to understand how it works. So first of all, here's the template. This is the HTML that we're actually going to render into the DOM. And of course, the most important things here are the data points. These are the parts of the template that are going to get filled with the model data. So what we're going to have is we're going to have a div and it's going to have a title and the content. That's going to be the title of the post and the content of the post. And this little funny thing here is just a way that Backbone has chosen to insert the template into an HTML file and have the browsers ignore it because the browsers will essentially ignore this line, this script text equals HTML. And this temple-backbone.dev.post is how we're going to identify which template we're going to use in our view. Well, it processes it, but it doesn't do anything with it because it's not like referencing an object to pull in or anything like that. So it's a standard tag, but it's kind of being used in a non-standard way. All right. So we are going to bootstrap a little bit of data so that our application knows how to reach the API. The JSON REST API, we're going to use this helper function, which is currently not in the 2.0 beta version, so I don't know why I had to add that to my PHP. But anyway, all this does is we're going to build a little demo data with the API URL using this function, and then we're using WP localized script to pass that data through to our Backbone demo script. That's the handle that we use to enqueue the script. So all that's doing is it's passing this demo data through and it's going to be localized to an object called demo data. Here's the model. So remember I said the model can handle syncing. This is where the model is going to reach out to the server and get its data. So first I want to, I'm overwriting the default sync method. So the model has a sync method built in, but I want to do something a little bit more with it, like I want to change the URL that it hits. I don't want to hit the standard Backbone URL, whatever that is, because I want to hit the REST API URL. So I'm over writing again or extending the, I'm extending the model and I'm overwriting this sync method. This is basically like overwriting a class in PHP, something very similar to that. And I'm passing the URL in. So this is the URL and I just hard coded post number one because I'm just doing hello world on a demo site. Probably should be a little more sophisticated, but we'll get there. And then I'm just returning the original callback. So I'm just basically going up the chain. This is the data that the REST API returns for that endpoint. So when the Ajax request goes out, it returns this data and most importantly the title and the content. That's the data that we're looking for that we're going to populate into our template. So here's the view. This is what does the magic of taking the model's data and rendering it in the template. Here's where we're setting up the template. That string there matches what we saw before in the template. And I'm setting it up with the WP template object. And when I go to render this item, I call this little kind of special formatted thing that basically takes the data. This is the model attributes, which you can think of as the data. It runs it through the templating function. And then it inserts it using this is basically just vanilla jQuery right here. This dollar EL is an object that's built into every view. And it's the element that is represented that that view represents on the DOM. So all this it does here is kind of complicated, but it's taking the data in your model and putting it into the template. And that's in the view now. So this is the basic setup of the application. Just a few more lines of code. Basically we set up our model. We set up our view and pass the model through to it. At this point, the model already has the data. And then we just append the view to the body. So in this case, I'm just dropping it into the DOM on a blank page. And at that point, we've got this. It's just a post. It's rendered. It doesn't really do anything. But it just shows you kind of how you get from point A to point B. You've got the data in the model. You get the template. You put it all together. And you have this nice screen. All right. And here's the HTML. This is the HTML of what we just saw. And this is exactly the template that we just looked at, except now here we've got the actual title and here we've got the actual content. That was the original, just to remind you guys, that was the original template. That's exactly what we have at the end. OK. Demo two. This is going to be almost the same thing, except instead of the detail view, we're going to start with a list of posts. You can click on each post and it will take you through and show you the detail view, the one that we already created in demo one. So this is building on what we have already, but adding a little bit of interactivity. We're going to use a collection to handle the group of posts, all the posts that we have on the site. And we're also going to bootstrap the list of the posts. So when the page loads, what we'll have is a list of the titles of all the posts and that's it. As soon as you click on one of those titles, it will make an Ajax request back to the API to get the actual content of that post to display. And it will also use the router in history so that you'll see that the URL will change. Every time you drill down to an individual post, the URL will change. And if you hash or go to that URL, you'll be right back at that detail view of that post. All right. Template. So the templates include the original template that we saw. That's also in this project, but this is the new part of the template. This is the post list item. This is going to be the list, each item in that list. And basically all it does is it has the data title and then it has a link that points to this kind of special URL that I made up hash post ID. And you'll see that I will process that later and pull the ID out to find out where I am in the application. And that could be anything. I just chose that as my format. Here's the bootstrap data. So again, we're going to have to pass the API URL so that we know where to make our Ajax request. But we're also passing this, which is a list of the posts. I'm just using this very simple, get posts, and we're just going to get 10 posts, and we're passing that in as the post data. There's the collection. There's nothing to the collection. It's just the default vanilla backbone collection. I haven't done anything to extend it. This is the collection view. So this is the view that backs up the collection. I'm telling it which template object I want to use, the list item template. I'm setting up the collection here with the pass-through collection, which we'll see in a second. And then I'm telling it to render. And then for the rendering on this collection view, what I'm doing is I'm going through each model in the collection and basically doing the same thing we did before, taking the data that's behind that model, applying that to the template, and then rendering it to the DOM. So what that's going to do is it's going to render each one of those post titles. Here's the router. So this is the object that's going to handle a URL in the browser and pass it through to create, to go to the right state in the function. This post colon, post ID, is the equivalent of hash, post, and then a number. And that number will be in post ID. And what that's going to do is it's going to call this post route function. So when you go and put post, hash, post, and then a number, it's going to call that post route function. And what the post route function does is it basically sets up a new post view, which is very, the exact same as the view that we had in demo one. And then it just calls a refresh function, which is a function that I added that we'll see in a second, passing through the post ID that you just put in the URL. And here's the refresh function. This is the inside the view. And it basically takes the ID through and it creates a new model with that ID. And then it fetches the data from the server. And when that fetch comes back, it renders itself. Very simple. And it's exactly the same view that we had before. So we already had this view. All I did was now added a functionality where you can pass it an ID and it will call that ID back from the server. Here's the setup. We set up our collection and we pass it the bootstrap data, the list of posts. We create a new collection from that. I'm sorry, a new view from that, passing the collection like we saw before in the setup function. We set up our router and we tell backbone to start the history object, meaning it's going to track the URLs in the browser. And we append the whole thing to the DOM and we're done. And this is what it looks like. I created a little recording so that you could see it. So as I'm clicking on these posts, you can see both the URL in the top is changing as well as the content on the right. So each time I click on one, you'll see the ID at the top changes. I just refreshed the browser. You'll notice nothing changed because it went right back to that state. As soon as I refreshed, the router just fired it right back to the same state. I'm hitting the back button here now. I'm going back through the different states of the application. So you can see each time I hit the back button, I went to a different URL and the content changed to reflect that. Any questions? All right. Yeah. That's the default. In WordPress, we use question marks for better backwards compatibility. But you can use whatever you want, basically. But if you don't put anything there, it'll be hashed by default. Yep. So I did one more demo for this talk because I know I had a little more time. This is now just like demo 2, but now you can actually edit the content. So what this does is it writes the data back to WordPress using the REST API. To make the content editable, I'm just relying on HTML5 here. So I just added content editable to the two fields that I wanted to edit, the H2 and the div surrounding the content. By the way, this data content rendered, that's actually how the JSON REST API version 2 returns its data now in this rendered data point, not in data.content. It's data.content.rendered. So they've actually changed the API a little bit and I had to change my demo code. So I'm pretty sure demo 1 doesn't work anymore. But demo 2 does. So changing APIs, you have to watch out for that. But I think version 2, I don't think they're going to introduce any breaking incompatibilities. So you're safe if you go with version 2, I'd say. Anyway, here's the content editable parts. And I have to handle the edit events. So in our post view, I'm going to add this events callback. And basically, I'm saying on any input event, on a content editable area, this is like a jQuery selector, I'm going to call this debounce content editable change function. You guys remember what debounce was, right? I don't want every time someone inputs anything to call the save function. I only want to call that when they've stopped typing, for example. And there's the build of the debounce content editable change. It basically just debounces this call, content editable change. And it only happens every half second. So here's what happens. We have to get the data out and we make sure that the data has changed. So there's a section before where I stored the data that was in those already, because we don't really want to fire off the save event if you haven't changed anything. So that's all I'm doing right there. Yeah. And there I'm storing the current data now. And then this is where we save. So it's just a standard backbone call, this.model.save. I'm passing the title and content. And then this little magic here is what I figured out is required to pass the nonce that's required to a member I mentioned you need a nonce with any address request. So in order for this to work, you do have to be logged into your WordPress instance. So it's relying on two things, both the nonce and your login cookie. So you obviously have to be able to edit the posts on your site to be able to edit them on the front end. And this is what the result is like. Again, we're back in the same view that we had before. But now I can click in and I've got this nice editable. Make some changes. Whoops. Right? And it's actually saving in the background. You can't even see that it's happening. But I'm going to go into the post editor. And there it is. There's my edited post. Right? Add some exclamation points. Change the word. This is great. There's a little bug in there. I don't know if you noticed, but I'm not actually updating the title on the left-hand side when you change it. So I probably could fix that. But if you look at the code behind this, it kind of completes the picture and shows you how you can send data back to the REST API to save information. So it's kind of like the final piece. Any questions? Yeah? How do the changes get posted to the database through the REST API? Yes, through the REST API. Yep. So that was that save call. That's going to, basically the normal backbone save call makes a REST put request. And all I did was I added the data points that I wanted to send because I don't want to send everything. I just wanted to send a title and content and the nonce that I needed to kind of authorize that action. Where do you find backbone that is in WordPress? Lots and lots of places. You have to go to that. If you go to that demo thing, the examples, you'll see it. It's all over. It's used by... Is that a drill ball or a dreamer? I don't know. I can't speak to that. I'm not familiar with those platforms. There is also another even more complex example on my GitHub where I created a directory of people that are attending a WordCamp by scraping the attendee page, which apparently no one has anymore. So I'm going to have to figure out how to get the data in there now. But basically, I store that information into a CPT and then at that point, I'm using the rest API to pull the data out. It's a little fancier, but it's basically the same idea. It's a grid of views and then you click and you get a detailed view and it tracks state and so forth. So it's just a little bit more detailed demo. All right. So this is my last slide. I'm just going to offer you this nice piece of pie and tell you that you should get started with backbone because it's awesome. It's fast. It's lightweight. It's used extensively in WordPress core. So by improving your knowledge, you're going to improve your ability to work in core and to work with WordPress. And it's just awesome. When you use it, you're going to create great experiences for your users. And you can use it on small things, a widget. It doesn't have to be like a full blown Pandora application. You can use it on any kind of interactive thing that you're building where you're writing JavaScript. And it's more than just a click and you want this one event to happen. When you start to have multiple events happening or have states where you want to store where the application is, that's when you start thinking about using backbone. All right. So I mentioned I work for 10 up. We are hiring. So if you're interested in working for a great company that's in the WordPress sphere, come talk to me. I love JavaScript. I'm big into contributing to WordPress core. It's my favorite thing to do. I got stuck with maintaining revisions in core because I rewrote the interface. And I've got a bunch of resources here that will be also on the slides that are on my website, tunedin.net. But I have to post up the new version because I added some stuff. This page here is just really great. This is the guy, Josh. What is it? Oh, Jeremy Ashkenos, right. Who wrote backbone. And this page is just full of awesome resources and extensions and things that people have done to build on top of backbone. It's a very minimalist framework. So when you want to do things like add local storage or memoizing, interact with React, there's all kinds of extensions people have built on top that so get you going on whatever you're trying to do. There's also this free book. This is a free open source book, backbone.js applications. You can go download it. I mentioned Mark Jacobs' talk. Just a bunch of great resources online. Again, they're on my website, so you don't have to worry about getting it off of here. And that's my talk.