 He's a much better speaker than I am, so you'll really enjoy his talk. So if you are really thinking about doing some work for WordPress.com, I think, and of course, building themes to JavaScript and the rest of the API, concentrate on this talk. Hi, run. So this talk is kind of going to be like the opposite of what John was just talking about because lots of the basic concepts that John was talking about, I'm going to throw out the window. So most things relating to building themes with JavaScript and the rest of the API are completely different to how we've been building WordPress themes so far, and I've been talking about this quite a lot over various WordCamps and stuff, so if I speak too quickly, then put your hand up and slow me down. I'm going to go through quite a lot of different topics. I've got some lots of live demonstration things, so lots of scope for this to all go wrong, but we'll see how we get on. So the way we do things now, John has just been talking about this. At the moment, we build themes with PHP, as you all probably can guess. We have little interactive bits of JavaScript, so we might have carousels or picture galleries, that kind of thing, but broadly speaking, the websites are built with PHP, and JavaScript is just a little side thing that we use a little bit, and maybe we use jQuery or something similar. So we always need a solid internet connection because the way that our websites work at the moment is that when the user clicks a link, the browser checks the internet, goes to the server, gets the content, brings it back, shows it. So that creates, I think I have a slide for, yeah. So what does this look like? You all sort of know, but I've got a demo, which I'm using the Chrome DevTools to show off what I mean by this. So if we go to something like the Straits Times, I'm using the iPad view just for the sake of it, doesn't really matter. And I'm throttling the connection. So this is just a normal, this is a 3G connection, a good 3G connection. Now, I know that people in Singapore don't have to deal with that. You normally all have 4G all the time, even on the MRT. But in London, it's not like that. So if we go to thestraitstimes.com, this is over a good 3G connection. And you can see that those actually pretty quickly. The Straits Times is actually a pretty decent website in terms of its performance. And if I click around on to a different story, if I click to the story, that's pretty quick. That's very good. I mean, considering this is just 3G, and I can go to the homepage. Now, obviously, although I'm on this website, and I just clicked on to this story about the former Malaysian Prime Minister, if I set myself to now being offline, by changing this to offline, I'll try again. If you don't guess what's going to happen. Oh, it does work. Cash. Yeah, but it doesn't. Oh, okay. Right. That's what I thought. So that was just trying to get back as well to the main homepage. So it's gone. The cash here, the cash shouldn't work. Anyway, but there we go. It didn't work. Good. Maybe it won't come. Yeah, Craig maybe hadn't actually gone offline at that point. But so I'll put it back on again. And if I press refresh, we should come back out. There we go. So yeah, you've all seen websites. So the problems we have in that sort of traditional way that we've been building websites, and it's not just WordPress themes. It's all websites. Is that when we think about how a mobile app works on our phones and our tablets and everything else, they're a lot smoother there. When we go from one bit of content to another, there's an animation, it's smooth. But on the web, when we click a link, page goes white, we wait for a couple of seconds, this page comes back. And obviously, if we're on a really good fiber connection, that's quicker, but it's still not that great. I'm bearing in mind that a lot of the time people are using the web on their phones or on their iPads. And iPads and phones are much slower anyway, because they have the whole handshake thing just takes longer when they connect to their Wi-Fi or they connect to the cellular signal. It's just not, yeah, it's not brilliant. And when we think about what we've become used to on consoles and apps and everything else in games, it's really nice and fast and quick and slick. And the web is just like slow and nothing moves and it's boring. And it's fragile because Singapore is really, really good on this. But if you ever lose connection, which if you get a train across the UK, this happens constantly, your connection keeps coming up and down and up and down. And if you're trying to do something online, it's really annoying. You keep losing connection. You keep a page, keep saying, I can't be displayed. The Wi-Fi disconnects. If you've got Wi-Fi on the train, it's all rubbish. If you go on the land and underground, you lose connection. If you go on the New York subway, you lose connection. So imagine you're not in Singapore because Singapore's great. But yeah, so it's fragile. The minute anything happens to our connection, the whole web breaks and it's all gone. And we've lost everything we had. Even if we've already been on something, we can't get it back. It's broken. Now, the main way that we can improve this is through JavaScript. This has become sort of an ever-growing thing for us as web developers. I really like this quote from Douglas Crockford. He wrote a book called JavaScript the Good Parts. It's a really good book. I'd really recommend reading it if you haven't already. And it's a really good way of learning a lot more about JavaScript. But JavaScript is the language of the browser. So, will we be getting the slides out? Yeah. This is being recorded. And I will share the slides. There's a lot of this isn't slides, so I will share the slides. But on their own, there won't be that useful. But I'm actually creating an online workshop at the moment, which I'll be doing probably next week. So everything I talk about will be available online somewhere in the next few weeks. And I think this is probably already somewhere on my speaker deck or something. I'll share stuff. And just ping me if you have any questions. Yeah, so Douglas Crockford says that JavaScript is the language of the browser. And it's absolutely true because that's the only way of actually telling the browser to do things differently to how the web traditionally works is through JavaScript. And as I'll come on to later, there's lots of new technologies now emerging in browsers. And the only way to use those technologies is through JavaScript. You need it. So I've got another demo. So if we go back to our little straight science example, which is quite nice, we have a website on webpress.com, which uses the REST API and is built with JavaScript. And hopefully load. This is also throttled. So this is also going to take the same kind of time to load. It's similar. But once it's loaded, the content that it loads is stored in the browser's memory. So when we click on, say, this first story, it's instant. It loads it really quickly. This website is called Quartz. The URL if you want to have a look is qz.com. There are VIP on webpress.com. And I just really like this website showing off how you can build something much more interesting. And if we click back, it's really, really fast. Now the straight science was quick. And in some ways on this kind of example, it's not that much faster. If we kind of go between the two, we click on, say, that story, and we click on to this story, how to put an egg. So that's now loaded already. That's loaded. But we can get back. Back. Yeah. I mean, the straight science is pretty well, but it's taken a while. It's having to reload the same things that it already had before, whereas the Quartz website just goes straight back to where it was before. Now here's where it gets really interesting. Let's go offline. Now bearing in mind that I actually haven't gone on some of the articles on the Quartz website. So I've gone offline. If we now scroll down, and I haven't pre-loaded this, honestly, if I now click on, so we are now, it's been a few seconds, we're definitely offline. If I click on, say, this story, keeps working. So if I was on a train or on an underground or whatever, I can carry on using the Quartz website because I've already started using it. I can walk into a train station. It carries on. It doesn't have the image. There was probably an image that's supposed to go with this, but it's giving us what it does have. So we've got a few broken images, but it's better than nothing. We can get back to the homepage again. It carries on working. And just to double check, this is definitely not the case with something like the straight signs. And I'm not picking on the straight signs because it's the same with the BBC, but so now we've gone offline. If I pick onto a story, now it's working. How is it working? It is again. Okay. Right. Let's have a better example. Let's go to one I didn't already go to. So once we have the straight signs back up, is it coming? There we go. Right. I will now go offline and I will go on a story that I haven't already clicked on. So this one doesn't work. Good. Right. That's my point. So whereas any story on here, we can get to anything at all and Quartz just carries on working. And I'll talk about one of the reasons it does this and why it does this, but when you think about it, when you're building a normal WordPress theme, when you get data, when you run the loop, which just happens automatically on index.php, which is normally the landing part of any theme, technically you go to the database and you get the data that would include the content. You get the data that would include the full post, but you don't use it. You just use the title and you have a link. So when the user comes, they see the title and the link and they click it. And then you go back again and you say, yeah, now I want the title and the content again and give it back to me. But when you use a REST API and you're using JavaScript, you can keep anything that you get from the database that you might want to refer back to. And that's how Quartz does this. So it's quite nice. It's not the only reason and obviously they're not really doing anything flashy with animations or anything, but it's certainly a bit more app-like. It's not doing this whole white page, we wait, comes back. It's just quite cool. It's nice. So I'm going to place this now. Oh, and I've got another thing I'm going to show you. So that was Quartz. I had a project. This is called Picard. So me and my team at Automatic, we had a meet-up. This was actually at the start of this year and we wanted to make a theme that used JavaScript and the REST API. So this is quite a lot like Quartz. In a way, this won't be that exciting because I've just shown you Quartz, but it's something we made. We made it quite quickly. It was, I think, a couple of days. So I've actually got it recorded as a video only because this is on GitHub and we are working on it and we've kind of broken it at the moment. So I can't show you the live demo. So I'm just going to show you this video. This was, this was in a browser. This was working normally. So I'll let this run. So you can see as we click on different links, it happened. It just loaded it instantly. It doesn't go to the server. It's a similar thing to what I'm showing you, of course. So we could, we could be offline. We are online, but yeah, it just works. And there's some really nice things. If we go into a post on the homepage, you can see this is the post. It's just loaded it straight away. It's quite exciting. And I think I click on the left icon in a sec and it animates between different posts. So the previous and next post links are instant and they animate. Slightly janky. We could make that probably better by improving the performance. But you can also use keyboard navigation with this. So I was using the left and right keys on my keyboard and that animates between the different posts, which is pretty awesome. And as you go between each one, the content is all changing as well underneath. I scroll down in a sec and you can see it's different. This is Star Trek Ipsum, which is just Star Trek rubbish that you can just put into your posts as demo content. So I think I also have an example of the commenting system, which is really nice and smooth and it doesn't involve waiting for the page to refresh. That's awesome. It's called Picard, by the way, because it's the next generation of themes. That was the kind of joke for any Star Trek fans. So this was a fake comment by Matt. He didn't actually say this, but we just used his email address. So it looks like it's... So I think I type in a reply now and you'll see how the comment system works. Need to email me? That's the email address. It's not how they work wrong. And then you hit post. It goes straight in. It's really nice. So there's no refresh, no... And you've probably seen things like this. I mean, this is how Facebook and stuff works, but it's just quite nice having this within a theme. So now you might reasonably be wondering how does that work? Because obviously I've been talking about JavaScript and themes and not using PHP. So it's using JavaScript, as you probably guessed. JavaScript has changed a lot over the years. It was kind of... I remember 10 years ago, it was a bit of a joke. There was a website called Dynamic Drive where you could get these little things that you copy and paste and the whole crazy animated things. But it's become a much more serious programming language. And I think that really started with the release of Node.js, which some of you may have heard of. It's a type of web server that you can interact with using JavaScript. So you can run JavaScript on the server as well as on the client. And most people are used to just seeing it on the client. But actually it's not even just Node.js, I think, that really kicked things off. It was NPM, which is the Node package manager, which is basically like a plugin library for JavaScript. So in the same way that you can install plugins on WordPress, you can install almost any bit of JavaScript you like in your project using NPM. And the idea of NPM, being the Node package manager, is that you just circulated Node stuff, but actually over time, people have now created all sorts of just random JavaScript things that you can use. And loads of stuff on NPM has nothing to do with Node, really. It's just cool JavaScript stuff. There's people have shared carousels and all sorts on it. So it's quite an exciting platform. And then, of course, there's all these new frameworks that have all been kicking off. And I think literally not a single one of these existed five years ago, which kind of shows you how much things have changed recently. So we've got Backbone and Angular. Backbone is a JavaScript framework for building REST API-based things. So that could be useful for theming. Ember is another really good JavaScript framework. Angular is the one created by Google, which, again, is a really good library, really good framework for building applications and everything else. The one I'm going to be talking about today is React. I only talk very briefly about it, so don't worry too much. React is a interface library from Facebook. And it's really nice. And it's quite easy to get the hang of. And it's very simple compared to the other three, because it's just for interfaces. So it's perfect for theming, in my opinion. Now, some of the things that you saw going on, both on Picard and on Quartz, are to do with browser technology. And some of this technology isn't actually new. So the thing where you store data in the browser's memory is the Web Storage API, which I think has been around for about eight or nine years. So it's really not new. It's in, I think it even works in 98. And yeah, it allows you to store basically any data you like into the browser's memory and call it back through JavaScript. We then have other things like the History API, which, again, is not that new. The History API allows you to change what happens in the browser's history. So whenever I talk about JavaScript themes and that kind of thing, a question I often get. Well, the first question is about SEO. How do we deal with SEO? Because you're rendering stuff without a server-side version. So how do the crawlers know what the page actually says? And the other one is, well, what about when the user presses back? Because they're going to lose where they've been. But they're not, because luckily we have the History API, which means that you can, if you simulate changing pages, like you saw when I went left and right on the Picard page, you can tell the browser's history that you have changed pages. And then you can press back and it will go back and it will just work normally. And then there are new technologies, like Service Worker, which isn't here yet, but it's really exciting. Actually, it is here. It's in Chrome, but it's not in Firefox or Safari just yet. But it's coming. And it's really exciting. Service Worker, I'll try to summarize in two lines. It basically allows you to change what happens when the user... Well, it allows you to run your websites offline. So when the user first types in the URL for your website, if they've been to that website before, and that website has let the browser know that it can work offline, then before the browser will even go to the internet, it first just checks the browser's memory. So you can have a complete offline website that works from scratch offline. So you can hit refresh when there's no internet connection and it carries on working. And you can get on a plane and you can use it. So there's all sorts of new things that this will potentially allow us to do. But in the first instance, in the case of a theme, it means it can carry on working when the user's not there. And the way it would work is that it will just use whatever it had last time. Now, that might be not ideal if you're running a news website. They could be a few days out of date, but giving them something is better than nothing, I think. And actually, in many cases, even if you are running a news website, if they have comments articles that maybe don't go out of date so quickly, they can see anything they've already, that they've already not even necessarily read, but it's just been viewed on their browser in some way. So yeah, so I think that's... I think the idea of something being offline is great. And there's obviously... You can change the way that you interact with the user. You can let them know that it's a few days out of date. There's all sorts of things we can deal with those problems. But it's quite exciting times. Now, JavaScript is one thing, but you may be wondering if we're using... And don't worry, I've got some examples that cover all of the things I've been talking about. If we're building stuff with JavaScript, which you hopefully all have some understanding of, or jQuery or whatever, you know how we can change things on the page and make little adjustments to what the user can see. How do we get the data? If we're building a normal WordPress theme, we have PHP and we can use the loop and all these different things to get different things out of WordPress, different bits of content and titles and links, and we can show those to the user. But if we don't have any PHP, how do we get our data? And this is where the next exciting thing comes in, and that is a REST API. REST APIs, for anyone who's not familiar, are actually not very complicated at all. They allow you to get data from your website over HTTP. So what that means is, instead of having to write a database query or write some PHP, you can just go to a normal web address and just see data. So yeah, I'll show you some examples of how this works, but you type in a normal web address and you just get data. It's in the case of the two WordPress REST APIs, it's JSON. Historically, some REST APIs used XML, which is just a different format, but yeah, you can get pure data. So you can say you want to get a post, you can go to a certain URL and you will just see the pure data for that post. It's ID, it's title, it's link, all those kinds of bits of information. So there's a WordPress.com REST API, which has been available now since 2012. It's available to any websites on WordPress.com. It's also available to any self-hosted website by Jetpack. So you connect your website to WordPress.com by Jetpack and you can access the WordPress.com REST API. But it's not brilliant for development because you can't extend it, you can't edit it because it's just, you're just a client, you can't do anything with it. More excitingly, there's the WordPress.com REST API. The project name has been WPAPI, so you can find it on GitHub as that, but I'll share links and everything afterwards. The WordPress.com REST API has been in development now for, I think, about two years. It started as a Google Summer of Code project and it's erupted. And I don't know if it was necessarily always going to be part of Core, but now it definitely is and it's been mooted for a long time to be going into Core, but it really is actually now going into Core. So the infrastructure is going into WordPress 4.4 and the endpoints, which are those links I was telling you about that you can go to and see data for your website, they're going in in 4.5. So 4.5, which will be out early next year, I think in springtime, that will have the WordPress REST API in it. But right now, I think I'm going to, yeah, so I'm going to now go to you some other tabs. If you don't want to wait until then, this is the WordPress.com REST API. I'll share the links for this, but this is more exciting. The WordPress Core REST API, which is available as a plugin and it has been available for quite a while now. So you can just install this plugin and you have exactly what the Core REST API will have when it comes out well at its current level of development. So you can just install this on your website and the first thing that this will do is it will create some new links. So I'm actually going to come out of presenter mode because that's not ideal for showing you this. This is full screen. Here we go. I'm going to make this bigger. So unfortunately, I can't make the top bit bigger. But so the URL I'm at at the moment, this is a test WordPress website. If I had, yeah, if I just go to REST theming.dev, that would be my WordPress website. So like anything.com. So a bit like how you have WP Admin where you go to the admin part of your website, you can get a WP-JSON. And then you see JSON data for your website. So the first page I'm seeing here is not particularly exciting and it also might look a bit like gobbledygook. Most of what it's saying here is just it's telling you about how the API works and what things you can do. So for most people, this doesn't really matter. The two things that are kind of interesting here is this top. This is the title of my website and the description, which is the strap line that you can also edit. So if I edit those, they would change here in the REST API. Now, the way these URLs work in the current version of the REST API is you go to something like WP slash V2 slash posts. So at the moment, the WordPress REST API, although it's not even in call yet, it's on its second version. The reason that they have these different URLs is so that they can add new things to the REST API and they wouldn't break everyone's websites because if they changed something in the REST API and you were relying on a certain URL, as I'm going to show you now, it could break things. So we now have posts. So if you imagine how the basic loop works, this is what you get from this top-level URL, which is essentially just posts. So it's going to take, by default, it's going to be the latest 10 posts from your blog. It's just like a blank loop. If you did the loop on index.php and you hadn't set any settings, you would get 10 posts. You can change that in the reading settings and it would happen. It would change here as well. So some of these things might start to look familiar to you. We have things like the title and that's like the underscore title. We have the content and you can see it's got all the HTML tags and everything that you would normally expect. You get all through information, which at the moment is, I don't know whether this is all for zero, comment status, ping status, certain things that you would normally be able to get through the loop if you wanted to. You then get the different links, different relevant things. So the link to just this top post because I can collapse that and we can see the next post. So that's if I scroll down, we can also find the next post. So here's the next post ID of one. This is the default post that you get with WordPress, the Halloworld post. You get obviously also the modified dates and the published dates and various other information. This is the normal link that they include, which is the permalink function that you would normally have. Now we can just go to one post on its own. So as I showed you at the top, this is post ID 1241. So if we now just add to our little URL here, 1241, we just get that first post. So if I scroll down, there's nothing more, it's just that one. I'm using a plugin just in case you're wondering on Chrome, which just tidies up JSON and makes it look a bit more readable. But just so you know, if you don't have that, JSON looks like this. So it's a bit yucky and it's quite hard to work out what's going on. But that's just raw JSON data. Once you get used to looking at it, it doesn't look that crazy. But if you haven't seen it before, it's better to use something like this because you can make human sense of it. So yeah, this is now just one post on its own. And again, I can change this to say one and we will just get the default Hello World WordPress post. There you go. Now you can see I'm just, I'm just going through a URL so anyone can get this data. It's another really exciting part about the REST API because it means if you're building something like an iPhone app, it's much easier to get data from a WordPress website than it ever has been because how have you done this before if you wanted to say on an iPhone, get data from your WordPress website. Not that easy. But now with the REST API, really easy. So I've got a couple of, I will post these links. This is the Mozilla developer network. I really recommend using the docs here. So there's a little bit here about web storage, for example. And I've got a list of, this is all the other web APIs. Now, almost all of these are exclusively available through JavaScript. So it's a very good reason to learn JavaScript. I'll leave that there. Another website which I really like, it was kind of marked when it first came out. It's called You Might Not Need jQuery, as you can guess, and it's youmightnotneedjQuery.com. What's actually really good is if you are used to jQuery, if you have used a bit of jQuery, and I know that that's quite popular among the WordPress community, it has examples of how to do the same things without jQuery. Now, sometimes that might look mad because you can see the jQuery example, and then you see the other example, and it's much, much longer. But sometimes it's actually almost the same. Now, I'm not trying to tell anyone they should forget jQuery and not use it, but my main problem with jQuery, and the reason I would recommend learning some real JavaScript, is that as good as jQuery is, you're kind of constrained by the things that jQuery allows you to do, and you're not able to go beyond what jQuery can do and try all of the crazy stuff that JavaScript allows you to do. So, who's still with me? Has anyone got any questions at this stage? Because it's about to get crazy. Because I've got some real code, and an example. That's a short question. Authentication? Authentication. If you want, or if you want to Yeah, that's a good question. So, authentication, how does that work? So, a lot of the endpoints for the REST API require a level of authentication anyway. So, at the moment, the system that they're using is OAuth 1, which you can look up. It's a way of authenticating a user. OAuth 2 is much better and much easier to work with, but OAuth 2 requires HTTPS. So, they're using OAuth 1. They're also using basic authentication, which is another way that you can authenticate. So, anyway, sorry, that's going to get me a bit ahead. So, anything that would be public anyway, like your posts, because you can get those through RSS, for example, already. They are accessible to anyone. Anything that you wouldn't be able to do by default, like adding a new post, which you can do by the REST API. So, as well as reading data, you can post data to the REST API. That requires some level of authentication. If you try and post without anything, it just gets rejected. So, basic authentication involves posting the username and password with your request. It's not recommended, because you're putting in the password in sort of open text. So, anyone who might be sniffing what you're doing over the network will see your raw password. So, you shouldn't use that. OAuth creates a token, basically, which the user gets a token, and that's trusted in the way that it's set up. So, you log in initially, create the token. The token comes to you, and it's unique, and it's, I think, 64 characters. And then you use that as part of your authentication, and then normally expire it after a certain amount of time. But yeah, that's the kind of easy answer. I won't try and get into anything deep with it, because it's, yeah, it's, I don't understand it, but yeah. So, don't worry. The REST API won't suddenly open you up to loads of problems. Like, it's anything that people can access, they could access already via RSS. So, there's nothing new. And I think with custom post types, you actually explicitly say whether or not you want them to be available to the REST API. So, it's just going to be, it's an extra attribute that's going to be added to custom post types. So, yeah, anything else? Cool, okay, right. So, I have a live demo. So, this is a really, really, really basic way of getting data from the WordPress REST API and putting it on page. And I'm going to show you the code that does this. Now, just to show, if I disable JavaScript, so do not allow, I'm going to come back to this. So, if I refresh this page now, you can see we only get the link. That's because the rest of that page was being rendered by JavaScript. Now, this also demonstrates why this could be a problem for search engines because search engine crawlers typically don't have, don't, can't run JavaScript. So, they're going to just see how they work on this page. Although, technically, this page should also show that other content. But we'll come to that in a minute. If I reactivate JavaScript, I hate the way it's so buried. Here we go. And it will come back. There we go. So, how does this work? Let's go into some code. So, I have just one pet file. It's called index.html. So, I'm not actually doing any for normal WordPress theming stuff. I haven't got any PHP at all. This is just HTML. And if we scroll down, this is visible to everyone, you can see I've actually taken the, this is the Ajax request to get content from the REST API. And this is taken straight from that. You might not need jQuery.com. So, in this example, we actually probably could use jQuery, but we're going to try and get on a different path and not use it. So, hopefully, what you can see from here, the XML HTTP request is part of JavaScript. And this you can, you basically create a new instance of it as a variable called request. And then we can say that we want to open a connection to this URL, which is that one I've been talking about. Which is that top post from the REST API. And then we say, if that loads and the response is greater than or equal to 200 and less than 400, i.e., it's responded okay. We're going to do a little bit of trickery, and we're going to change some content on this page to include data that comes back from the REST API. So, the response is a variable called data. We parse that JSON so we can access different bits of it. And you can see we have this data.title.rendered. Now, you might remember that that is how the content looks here. So, title, rendered, and we get the title. And then we're going to get the content as well, which again, content, rendered, and we get the content. And the .innerhtml function is just some pure JavaScript that basically replaces HTML on the page. With something else. So, we can say .innerhtml equals and it will change what's there. So, that's what happens when the page first loads. Now, we've also got one other exciting element going on here. If I go back to that page and I click on Hello World, it changes to another post. It's bad practice. The URL doesn't change. I can't press back. So, we're not doing any of the things that I said we needed to do, but it does work. So, the way this works, if we scroll down, it's basically the same thing again. We have a function called changePost, and again, this is kind of hard coded, so you wouldn't want to do this in a production environment, but it's just a demo. So, this basically does exactly the same thing, but it actually uses a different endpoint from the REST API. It goes to post with the idea of one, which is the Hello World post, and it replaces the content with that new bit that I've just said. And the way this is attached to the, if we scroll back up to the top, you can see we have this link that says Hello World, and it's got an ID of another post. And if we scroll down, you can see right here at the bottom. I hope that's visible. So, we're going to add an event listener, which is kind of jQuery, has an automatic way of dealing with this, and we're going to listen to click, and if a click happens on the element with ID another post, we're going to run the function changePost. So, we're going to change out the post. As I said, I will share this. This is just a really simple code just to kind of get people going with this whole idea. But this is theoretically a very, very basic WordPress REST API theme that gets data from the, sorry, JavaScript theme that gets data from the REST API. Now, I have a more complicated example, if you get to the next one. So, this is now a complete loop of posts taken from the REST API, and you can see we even get the basic formatting of something like a tile gallery. And that's going to work. It's going to get that and share that to us. This is just the theme unit test data that John was talking about. So, it's just all different sorts of things, different examples. I think there's some other ones with images in, and yeah, lots of different stuff. So, yeah, there's some images. And again, you get the very basic display settings that will work as you'd expect. So, oops, sorry. So, how does that work? So, now things get a bit more intense. And in this example, I'm using some React. Before I actually dive into this, I'm going to just quickly go to the React. That's what hopefully just worked. So, I'd highly recommend, for anyone who's interested in what I'm talking about, doing, there's a getting started tutorial with React. It's really good. And they explain a basic commenting system. But on their homepage, they have some quite nice live examples that you can just play around with. So, down here, you can hopefully see, we have this bit of code here. This is a very basic React component. And we can actually interact with this and change it. So, say we were talking about John here. He doesn't have an H, so we could take the H out, and it's correct. Hello, John, over here. So, basically, what happens here is that we create this component. That's the var hello, hello message equals react.createclass. And then we're going to say we want to render, and then we have our bit of content here. Now, it's saying, it's being given a prop, which is given here as an attribute. And you can see this looks a lot like HTML, because that's kind of what it's based on. And as that prop is passed in, it changes what's said. Now, we could take that out. We could just hard code something else here. So, we could say hello, sorry. We're pressing a pull. And again, that works. But ideally, it's good to have something dynamic that we can change automatically. And you can see the errors come up as well. So, we could also, for example, add another bit, which we could add this prop.sername, for example, which at the moment is going to show nothing, but we could add this in here. There you go. And that's showing. So, yeah. Now, the mount node bit at the end, that's just basically the node on the page that React is going to be shown in. So, you can see that we could start setting up a template here. This style of using HTML within JavaScript is a custom syntax that Facebook has created called JSX. It does need to be compiled. So, you don't send this straight to the browser because obviously this, as JavaScript, wouldn't work because it has some actual HTML in it. But they also show you conveniently on here what the actual JavaScript looks like. So, it's just a little bit more complicated. And instead of having these little just written out normal HTML divs, it does this thing. Don't worry about this too much. It doesn't really matter for our example. But yeah, we can write normal HTML in JavaScript, which I find quite exciting because that's kind of what people do at the moment with themes in PHP. You write normal HTML in PHP. With React, you can do it in JavaScript. So, here's our little example. Now, some of this is quite similar. Some of this will probably look quite alien to a lot of you because even just this very first thing I'm doing where we require React. So, this is using a convention in JavaScript known as CommonJS. And CommonJS is a convention around packaging JavaScript into multiple files. So, in the way that you can currently include in PHP or require in PHP, the CommonJS system is based around having that same functionality but within JavaScript. Now, the way that it's ultimately sent to the browser is that we process this somehow because, obviously, again, you can't just require something and put that live on the server and you'd have lots of different JavaScript files which take ages to load. So, you use something like Gulp or Grunt, which some of you may have heard of, to compile your files into one single file in the end. But yeah, so this basically means that we can require React. Now, when we require React like this, and it's just a straight-up string, we're using the Node package manager to do it. So, it will, I'm probably losing people, I'm aware. But, yeah, we can basically use anything that's on Node package manager through this system. We don't really have to know how that's working. It just works. Don't worry about it for now. So, you can see this first part is very similar. So, we're using these methods that React has. Component did mount means the component has loaded on the page. So, the first thing it's going to do is get data from the WordPress REST API. Let's scroll down. We can see it. It's just like the other thing I showed you. But instead, when it gets the data back, instead of doing that really basic thing I showed you, it's actually going to pass all of the data from the REST API to this component called page within a div. And that's where the data goes when it starts. Again, we're not handling any errors or anything like that, but the request gets sent. Get initial state is another basic thing that React does. So, it's saying that before anything is loaded, just show an empty div, which it does. And when it renders, it's going to render the component, which I've set up here, which is called page. So, you can see we set the state component. That's our page. So, I know some of this probably will seem nuts, but this will hopefully look vaguely familiar because now we're getting back to normal kind of WordPress-y stuff. So, here we have our template structure, which you would see in a similar way to other scores, and we're using the same sort of classes. One weird thing about React is that class is a protected term within JavaScript, so you can't just say class. So, you use the class name attribute, but basically that creates a class. So, it's exactly the same. You just can't use the word class. So, you can see we're populating this template with bits of real data from the REST API. So, we're creating links, and that's going to be post.link, post.title.rendered. And, yeah, this thing that happens at the start, that's a bit like a for-each. So, what we're saying is that for each bit of data, we're going to pass it into this function as a post, and then we can take any data from each of those posts that we had. So, that's that. You can see we've got the post-date coming in as well. And then this dangerously set inner HTML is a thing that React has by default. They escape everything by default with React, and John kind of spoke about this, but as you probably saw, we had HTML in the response from the REST API. So, we want to explicitly tell React not to escape the content, because the content has HTML in it, we know that. And it's, there might be a more secure way of doing this, but that's what we do for now. This certainly long thing is just the way of them trying to make you realize that you shouldn't do it. But we get the post-content.rendered comes out. And, yeah, so we create this variable here, this post-nodes, which is going to be basically like an array of posts, and then we render them onto the page here. And that makes up our page. And at the very bottom, we have React.render, and we're going to render this whole component, which is called controller. That's the very top, like all the way back up. The whole thing is called controller, and we render that onto document.body, which is just the body of the website. And we end up with this, which is just a list of posts. That's kind of it. I will... Yeah, I'm at React Linux on most things. We have the full Picard theme on GitHub. It's under the automatic user account, and there's a Picard repo. So it's github.slashautomatic.slash Picard. But I'm always talking about this stuff. I'm at React Linux on everything, like GitHub, Twitter, Instagram, if I want to look at my photos. But, yeah, if you want to ping me about anything, feel free to do that. And if you want to ask me questions, stuff after this talk, I hope that's made some sense and I'm happy to answer any questions and ask questions, if they want to be to ask questions. But, yeah. Anyway, thank you very much. Cheers. Questions for Jack? I think everyone's minds are blown. Did I get you high? Yeah, sorry. But here's a key takeaway. If you want to use current ways of creating things, use child themes, make sure it's also secure. A lot of resources online, such as parent and child themes or how to create WordPress child themes, probably pages and pages of tutorials from WP beginners or especially magazine. If you want to go to the next generation, you're going to go ahead, look at what Jack is talking about. You don't actually have to understand all this if you are not a developer. But if you meet a developer or you're looking for a theme online, use these search terms to find something great for you. I think this is at least a takeaway you have today. So, um, Jack is actually from the UK, so he's only going to be here until tomorrow. He's going to fly away. So if you want to pick his mind later on, you've got limited amount of time, yes. And then I'm going to pass it to Ben. He's going to do a little bit of housekeeping, kind of a thing. Okay, so just a last two things.