 Just a little taste, because I have a lot to cover. So we're going to jump right in. Thanks, everyone, for coming. This is my talk about JavaScript APIs in WordPress. Someone will probably be quick to point out that this really isn't about APIs. It's about functions and utilities and helpers in WordPress and outside of WordPress. But again, there's a huge amount of stuff to cover, so I'm going to jump right in. After the talk, I'll post up the slides and all the links that you'll see here up on my GitHub. So this is the one address you'll need. I'll also have this up at the end. But don't worry if you miss something, because like I said, I'm going to move really quickly. There's a lot to cover. And I'm just going to cram it all into a half an hour. My goal is to just have your head spinning by the time you leave here with ideas and things that you can do in JavaScript in WordPress. So there'll be code samples, but I don't expect you to be able to catch it all. So remember a few years ago, Matt told us all to learn JavaScript deeply. I hope everyone's been taking that to heart, starting to use more JavaScript in your themes and plug-ins and embracing the idea that JavaScript is the future. I think the deeply part is learning the frameworks, the build systems, and all of the tools that make up the modern JavaScript stack. And that's where we're heading. Soon, you may be building a feature or a theme or a plug-in that's entirely in JavaScript. Speaking of building, we recently introduced Webpack to the core build process. And what this, thanks to Omar Rice, and what this does is it enables us to organize the JavaScript in WordPress in a logical way and then build it back into place into the traditional legacy places for backwards compatibility. It also sets us up for modern JavaScript coding practices like we're using in Gutenberg. Oops, that went two slides. Go back. OK. So JavaScript in WordPress. Increasingly developing for WordPress has become a JavaScript proposition with the introduction of the REST API and now Gutenberg. JavaScript is going to be the language that we're going to be using to develop features for WordPress. Traditionally in WordPress, all of the JavaScript we've developed has been put on the WP Global, windows.wp. And this is where all of the features that our JavaScript features in WordPress live. So the WP namespace is modular. This is what you get when you type in WP in the console on the post edit page. And each one of these objects is worth exploring. I actually encourage you to take your console and just type WP in and see what you find. There really is no place to find all of the documentation about these objects. However, it is something that we're working on now. And what I'm going to do in this talk is cover some of the more interesting objects tools that are available to you and kind of give you some ideas about how you might use them in a project. In terms of documentation, Anton has been working, leading an effort to add inline documentation to all of the JavaScript in core. There's a link there. There's an initiative going on. It's a great way to learn about the JavaScript if you want to get involved. And ultimately, we will be able to take these inline comments and process them into the developer handbook, just like we do with our PHP documentation. This is a picture of bread. It's not related to my talk. It's just a reminder for me to take a break. I did bake the bread, though. All right, let's dive in. WP Editor. This is the JavaScript way of rendering a tiny MC editor into your application. It's the same tiny MC editor that editors are already used to using on the post edit screen. And it is great for adding an editor anywhere you want. You can add it in a meta box or maybe on the front end. But if you're building something in JavaScript and you want to create that editor experience, this is what you're going to use. So I have an example of using this in a React component. This is something I built for the live blogging solution from Automatic. And in the original plugin, they're using a React-based editor. But we wanted to provide the tiny MC editor. So the code to do this is fairly straightforward. And the render method of the component, we insert a text area that will become the editor. And then later in the lifecycle of the component, we just call WP Editor Initialize. And again, with this tiny MC editor, we have all of the same features that you would have in the tiny MC editor in the WP admin. So you could have custom plugins and things like that you've developed for tiny MC. And I do expect that we'll see something similar with Gutenberg once it merges into core that you'll be able to similarly instantiate the editor part of Gutenberg in other places. WP Code Editor is similarly an editor, but it's designed for editing code. And it's also great for syntax highlighting. We introduced it in WordPress 4.9 to enhance the theme editor and plugin editors in WordPress. And it's also used for the CSS editor in the Customizer. So this is what it looks like. It gives you this rich editor, nice highlighting. But you can also use it in your theme or plugin for something that you're creating. So as an example of that, this is an ads.txt plugin that we created at TenUp. And we use the syntax highlighting to highlight the format of your ads.txt file and hopefully make it easier to avoid introducing potential errors. So here's the code for this. Again, very straightforward. We add a text area where we're going to put in any existing content. We enqueue our JavaScript and also the styles required by code editor. And then in JavaScript, we call WPCodeMirror from text area. And magically, our text area turns into a rich code editor. WP media. So this is one you're probably a little bit familiar with. This is what we use to extend the media library and leverage the media library in WordPress. In your JavaScript application, you could use this to allow people to insert from the media. But you can also customize the media editor. It's quite complex to the media, WP media. So there's a lot of different parts of it. When you look through that, there's many views, many models. And it could be quite confusing to decipher where to start extending it. So a couple of tips. This is probably my favorite guide to WP media. This is a plugin from Eric Lewis. He also gave a talk on WP media at WordCamp Philly 2014 that you can watch on WordPress TV. The great thing about this is that the guide is built as a WordPress plugin. You install it into your WordPress, and it gives you this nice guide to all the different parts of WP media. And because it's a plugin, you can actually interact with it directly in the browser. You can see how it works. You click on the button, it opens the media library, inserts the image. So it's kind of a real-time example of using WP media. I love to call out this plugin from Felix. This is a really good example of extending the media library. In this plugin, Felix has added categories and tags to the media library, and kind of has done it what I consider to be the right way. So let's look at the code really quickly. This is kind of the standard approach for how we extend WP media. First of all, here the code takes the default attachments filter object view and extends it with a new taxonomy filters view. Just overwriting one function create filters, and that new version of the function is going to add the category and tag filters. The second step is actually overriding the core attachment browser object. So here you can see we're actually replacing the attachments view object entirely with a new object that uses our taxonomy attachment filters that we created in the previous step. And that's going to give you the customized version that WordPress will then use when you open the media library. All right, another breather. If I don't have these in my talk, I'll just talk really fast and be done in like 10 minutes. WP heartbeat. So this allows you to send data constantly back and forth on a regular cadence between the client and server. And we use it in core for post locking and for autosaves. And it's great when you want to send regular updates to users like a progress bar or a dashboard of scores or statistics. Oops, skipped ahead again. Come on. All right. As its name suggests, heartbeat runs at a regular pace by default every 60 seconds. But you can adjust that. And data can be sent back and forth between the server and client on each of those heartbeats from multiple different connected applications. It's very well documented, but it's important to note that some hosts do disable heartbeat because of the added load that it adds to the server. So here's an example that we built, extending the import tool from Penske MediaCorp. This is an open source tool for importing posts. You can use it, for example, for importing posts from production to staging to test them out. And we extended this with a batch mode that enables you to import an entire category of posts. So what this does is the user selects the category. In this case, they're called verticals. Once they select it and start the sync process, heartbeat begins to regularly send information back and forth from the server and updates the progress bar. A nice thing about using heartbeat for this is you can actually leave the page. The process is happening in the background. When you return to the page, you'll still get those regular updates. Take several minutes for this process to occur because it's importing all the images and everything. So it's good to have a way to update regularly, but also not keep the user tied to that page or some kind of constant polling. So here's how we make this work with heartbeat. There's two main events that we're going to listen for that it triggers on document. This is using jQuery triggers, the heartbeat send and heartbeat tick event. On heartbeat send, we're going to attach any data to the past data object that we want to send to the server. In this case, all we're sending to the server is the sync type that we want to use. Then on the heartbeat tick, this is handling the data that's returned from the server. We are going to use that data. It's going to give us the information about the progress. Whoops. Sorry. And we're going to use that returned information to update the progress bar. So this is how we attach the data on the PHP side. There's a filter heartbeat received. And in our callback, we look for the data request from the server. That's the sync type that's being passed. And then we're just going to return all the data we want to send back to the client. Here's what this looks like in the browser. As soon as I start the sync process, we'll start to see these admin Ajax requests going out. We've set the cadence here to every five seconds, because we want pretty much a real-time update to the user. So this is what the request looks like going out to the server. And then this is what comes back from the server. So with each heartbeat, we'll see a list of posts that have been imported and a list of posts that remain to be imported. And that gives us the information we need to update the progress bar. All right, the customizer, WP Customize, is the JavaScript API for interacting with the customizer. We've always had a robust PHP API for the customizer. But in 4.9, we also added a complete JavaScript API. So now you can do everything in the customizer, create panels, sections, controls, fully in JavaScript. And this allows you to create more dynamic types of interactions. For example, you could have custom controls that appear only on certain pages or certain contexts of the customizer, which you could do previously, but it was much more challenging. Now we can do everything in JavaScript. The customizer APIs are very well-documented. There's this whole section of the handbook. So that's a great place to start if you want to get into using JavaScript in the customizer. It looks very similar to the PHP calls. They kind of, the PHP API and the JavaScript API essentially mirror each other. Have to mention WP-Agex. It's our workhorse in WordPress. It's still great tool. Luke Woodward's article on it is probably still the source I would go to to learn exactly how to use it, but this is just a simple helper for sending requests to Agex endpoints that you've created in your back end. The break here. Hey, what happened? My slides are gone. All right, WP API. So this is the client helper library that's built into WordPress for interacting with the REST API. It's especially useful if you're using Backbone in your project to manage data, but you can use it in any project. It's really simple to use. You can queue the WP API script or make a dependency of your script. And what it does is it parses the schema provided by the REST API to determine what endpoints are available and creates models and collections for those endpoints. So for example, to use a post, I just create a new wp.api.models.post. Here I'm passing the ID of one, which will be the default hello post that comes with WordPress. And then because it says Backbone, we just do post.fetch to load the data from the REST API. And now my post object model is full of all the attributes from the post. Similarly, we can set and save data to the REST API. And the WP API client will automatically handle the headers that you have to send, the nonce, and all of the kind of details around authentication, as long as you're using key authentication and you're already logged into WordPress. This also works with custom post types or meta that you've registered, as long as you have show and REST set to true. So for example, if you create a books custom post type, then in JavaScript, use wp.api.models.books and book.fetch works just the same way as posts. You can also get collections of objects. So for endpoints that support multiple items, you get a collection back. It's built up of the models for each of the individual items. There's also these nice helpers. So you can get all of the kind of connected objects that come with a post, the categories, the media, the tags, the user. These helpers just kind of work behind the scenes to grab the additional data. At a lower level, we have wp.api request. This is used just to make a straightforward request to the API. But it also handles the authentication nonces and so forth. So it's perfect for just handling. It also knows where to make the request to. So it kind of handles some of the underlying details that you need to make a request with JavaScript to the API. There's a few more wp type objects that I'm going to cover here. And then we're going to move into kind of a slightly different area. So wpSanitize is a helper for making your JavaScript output a little bit safer. Probably wouldn't rely on 100%, but it's great for stripping out HTML tags and also encoding entities before you output HTML and JavaScript, which can present security risks. And wpA11y or accessibility has only one method. It's used to speak messages to assistive screen readers. And this is actually especially important for JavaScript applications. Screen readers have a hard time understanding when dynamic actions are occurring on the screen. So it's important if you have, say, like a search box with new content coming in dynamically that you use something like wpSpeak to announce those events to screen readers. So I'm going to get back to the word count one in a second. But we're going to talk a little bit about WordPress NPM packages. So you may have noticed in the last year that we've been taking code from WordPress and making it available on NPM. If you're not familiar, NPM is kind of the plug-in repository, I guess, of the JavaScript world. It allows you to pull in modules into your JavaScript project. And now that WordPress modules are made available on NPM, you can pull them into your JavaScript project. And you no longer rely on having those objects available on the WP Global. We'll get to why that's important. So there's a whole bunch of objects that are already there. And we are adding more all the time. So the great thing about using NPM, again, is you can build a JavaScript application that will run inside WordPress, but it could also run outside WordPress. Because you have the tools now built into your application, you're no longer dependent on running in a WordPress context. So you could create some code or a widget or something that could work on your WordPress site, but it could also work on a standalone kiosk or a static site or on another CMS. Gutenberg is actually moving towards making packages available in, oops, I'll let this scroll through because it's not going to the next slide. So the Gutenberg team has been making an effort to take their packages and move them to NPM, make them available on NPM as well. Like everything, Gutenberg, it's moving at a breakneck pace. Some of these are already available on NPM in beta form. And again, the great thing about this is you can use something like WP element, which allows you to render in Gutenberg. And you can write code that will run both in Gutenberg and the classic editor or outside of WordPress entirely. So I want to just show you the WordPress kind of example of how we would use WP word counter, the old way and the new way. So the old way is we enqueue the script in PHP, and then we can rely on the word count object being available on the WP global. So we simply call it in our JavaScript. The new way, there is no PHP. We import the word count object from NPM into our project with NPM install. And then in our JavaScript, we just can use that directly at another break. Moving into the modern world here, slowly. Yes, thank you. WP hooks. This is kind of an experimental API currently in Gutenberg. And it aims to be the equivalent of the PHP hooks that we have in WordPress. So again, you can add this to your own project by importing it from NPM. And you can add hooks to your plugin by using create hooks and add a hook object that you can then use to apply hooks anywhere inside your code base and make your code base more extensible. It has all the same functions that you're used to using in PHP. You've got do action, add action, add filter, apply filter, helpers like remove action, has action, all the things that we're used to using in PHP. I would say the one main difference that we have is we require a namespace when registering callbacks. And the reason for this is we need a way, we need a handle to be able to later remove hooks. In PHP, since we still support 5.2, we tend not to use anonymous functions. But in JavaScript, anonymous functions is kind of all the rage. And without a namespace, there would be no handle to remove those hooks. So here's an example of using this in Gutenberg. All blocks in Gutenberg are filtered. So what this code does is add a filter to the extra props part of blocks. And if you type this, drop this into your console, you will see that all blocks get a red background color. But you can also use it to filter individual blocks. In Gutenberg, this is implemented as a higher order component called with filters. And you can use this in your own plugins if you want to create something that can be filtered by other plugins. Or if you want to hook in somewhere and have something be able to be unhooked. All right, so shifting quickly to Gutenberg, I'm going to talk about a couple of the major APIs in Gutenberg that are available. I know there's other talks going on about Gutenberg, but I think it's important to get these APIs kind of in your mind as you start heading into the future. There's pretty good documentation in Gutenberg. There's this great handbook that's built. There is also great documentation in the GitHub repository. But it is quickly falling out of date. It's a little hard for them to keep up with all of the development as quickly as it's happening. WP Plugin is the kind of way that we fill data into Gutenberg. So there are slots. And WP Plugins allows you to fill those slots with your own custom components. You'll find documentation on the GitHub repository. It's slightly out of date. But it essentially works like this. You register your plugin, and you pass it a render method. And that render method winds up filling a slot somewhere in Gutenberg based on how you name your components. You can find out the list of available slots that are currently available in Gutenberg just by typing wp.editPost into your console. And this is an expanding list as extensibility grows in Gutenberg. This is very similar to using PHP actions that we would do in PHP, where an action would fire, and then you would output some HTML, and that would appear somewhere in the editor. This is the equivalent of that in Gutenberg. So WP data is how we interact with and manage data in Gutenberg. And you can also use it in your own plugin. Again, it's available from NPM. So you can install it in your own application that you're building in JavaScript. And you can use it to manage your data. If you've used Redux before, WP data will be very familiar. It follows a similar data flow pattern. But it also has a complete set of tools for managing data in your own app for responding to data changes inside Gutenberg and actually for interacting with the API. So we add, fortunately, wrote this post very recently. It's completely up to date and has all the latest information about how to use WP data. He explains how to retrieve, update, and respond to changes in Gutenberg data, how to register your own custom data namespace, and also, again, how to fetch data from the REST API, all via this wp.data object. WP element is simply an abstraction, a top react. Again, you can install it from NPM. And it looks something like this. If you've used React before, this will be very familiar. There's kind of two main helper elements, helper tools here, createElement and render. If you're not familiar with React, this is very similar to using jQuery DOM construction and then rendering using HTML. All right, so this is kind of coming to the end of my slides. So just a couple things I hope that I've gotten you thinking about. There's a slew of tools available in WordPress in JavaScript that you can use. Learning JavaScript deeply means not just learning JavaScript but learning the frameworks and build tools that we use in JavaScript. That's going to be something we're all going to be learning as we build JavaScript in the future. And by leveraging NPM, you can create JavaScript applications that will work both in WordPress and outside of WordPress or, say, in Gutenberg and in the classic editor. And finally, I will encourage you all to get involved in Gutenberg. We need as much help as we can to move the project forward. And it's a great way to learn modern JavaScript deeply. That's it. That's the link. So I see you have a link. That's where people can find your slides. I'm going to post them after. I haven't posted them yet. I want people looking at it during my talk. So thanks for sharing that. I can imagine this was a lot of information that people may have some questions. And we have four micrones in the room. So who wants to have the first go? It's kind of hard for us to see. Oh, I see a hand here in the middle. We have the lights in our face. So if we don't respond immediately, just we're on it. Hello? Yes, it's working. First of all, thank you for a great talk. Just a simple question. I already started using Gutenberg. And when you create a custom block, I couldn't find it, maybe, by mistake. But is it a plan to make it available like we have with Metabox, that when we create a custom block that we can control it on which page is going to appear? To limit which blocks are available on which page, you mean? Yeah. There is a way to do that. I'm not the Gutenberg expert in the room. I'm sure there's someone who could tell you exactly how to do that. There are filters available that allow you to control the whitelist or blacklist blocks in the selector. But I wouldn't know how to tell you to do that offhand. Okay, so yeah. That's something we certainly will need as the number of blocks proliferate and some of them are geared towards specific post types or data types. Okay, thank you. Yeah. Any other questions? Here's one in the middle. So you were talking about the WP API and the models, like the default post models which has relations with taxonomies or tags. Yep. And there's automatically functions created to get these taxonomies for that tag. Yep. What is the best way to make functions to get custom relations with custom post types? So if you're using the WP API client, you could extend it just like you can with any backbone object. So you could add your own helper methods to it. That would probably be the best way. Also, the API will return that data as part of the single request if you use the embed context and the client is smart enough to know if you have the data already not to make an additional request. But I would look at the underlying code that does this and you can follow that pattern to add your own helpers. All right, thank you. Yeah, sure. More questions. Don't be shy. Yes. Hello. More of a vision question. How many years do we need before Gutenberg has world domination over every CMS in the world? Yeah, that's my favorite question everyone asked me at TenUp. They say, oh, when will Gutenberg be merged to core? And I say, oh, it's in April. Just not sure which year. When it's ready, when it will go to the other CMS is when they realize that how awesome it is, I guess. It should have realized already, right? Or not? Is that... It's getting there. It's getting there. Hopefully, and eventually. So any other questions? There's one in the back. Yes, thank you. Do we have a mic? Yeah, in working with... So you had the WP hooks objects. The front-end event model with Gutenberg for developers who may be used to working with the WordPress hook system on the PHP side, moving to debugging in a JavaScript context. I'm curious if you have any recommendations for debugging and tracking events as they happen in the front-end in a way that's as much as possible aware of WordPress and Redux and the different state management things that happen. Yeah, so a couple of things. One is learn how to use the Chrome debuger console. Like that is the most powerful tool of all time using JavaScript and I'm sure the other browsers also have similarly good ones. But there's a great React developer plug-in that you can install in Chrome that gives you some insight into what's happening inside Redux. Yeah, those are my two biggest recommendations. Learning how to use the debugger tools, dropping breakpoints, all that kind of stuff that you can do in JavaScript. I will say that in general, React can be very confusing to debug. The error messages that it spits out are often very cryptic. So I do spend a lot of time doing console log and adding breakpoints and tracing through code that way. Old school. Anyone, yes, okay. I'm just curious, you seem very knowledgeable about all the APIs. Just curious what you think will happen to WP media, for example, all the old backbone stuff. Yeah, I mean, I think ultimately we will rebuild WP media in React. I will say it does work very well as is. They haven't really had much problem integrating it into Gutenberg. It's probably not the top priority as the next thing to redo. And so I don't know when that will happen, but I think ultimately we will see it rebuilt. Even though it is challenging to extend and confusing, there are really great examples out there now in the wild. There's great tutorials, things that you can find, which is something where we lack in Gutenberg because it's new. So it's kind of a little, I think people are happy with it, so it's a little hard to change it. Also, it would be a lot of work. More questions over there? Can someone bring a mic? Hi, I have a two-fold question. First of all, I'm interested about WP heartbeat. WP heartbeat, it apparently uses a polling system, right, to fetch information from the server. Yes. Is this component here to stay, or are you planning to introduce some kind of a server push system, which could eventually replace heartbeat? And another question is more general. What do you think about creating verbous themes with a front-end entirely written in JavaScript? Do you have any opinion or perhaps a vision? Would it be a more common thing to see in the near future? Yeah, so the first question about heartbeat, I don't think there's any plan to change heartbeat to use anything other than the current polling system that it uses, obviously wouldn't be appropriate for a really large-scale front-end application because it would hammer the server. It's really more designed for the admin use where you wouldn't expect a lot. In terms of the second question, building a theme purely in JavaScript, I think, I think that's a brilliant idea. I hope everyone's thinking about that a little bit. It's really fun if you get into React, you realize the great thing about React is it's component system and the way that you can build things and reuse them in a very modular way. There are some challenges in terms of we're very used to the theme templating system, so there's kind of a new world that you have to explore about how you're gonna get your data out of WordPress, how you understand the context of where you are, how you integrate with things like the customizer and post-previews are challenging. But there are also some big advantages, especially if you can build a website that's like a single-page application. Once the page is load, it can be very quick to navigate from page to page. And there are some good examples of it. Us too, I think, is the game shop that has a GitHub repository explaining how they built their site, which is all JavaScript. And I think more and more people are doing this now and sort of publicly posting about how they've achieved it. So I'm excited to see people doing that. And also, I think plugins, you can write plugins that are largely or entirely in JavaScript and get some real advantages out of that. So we may have time for one long question with a short answer, or one short question with a long answer, so anyone who wants to give it a go at the last question? So if people have questions afterwards, are you around the whole conference? I'm around all weekend. I'll be hanging out in the community area at some point. Okay, and we have people watching the live stream, which is awesome. Are you available online for them to ask questions? Sure, yep. That's my Twitter handle there. You can also email me. I'm also on the course Slack. Adam Silverstein. Okay, well, thank you for sharing your knowledge and another applause for Adam. Thank you.