 All right. Hey, everybody. I'm here. I'm actually excited about this. So for those of you who don't know me, which should be the vast majority, I'm Surma. And at this point, it shouldn't really surprise you that I work for Google in London. So as Matt just said, I kind of wanted to piggyback off of the slogan that you have heard multiple times today. And you will probably hear a few more times today. And I'm sorry about that. But most of the time, it's true. And we used that slogan also already excessively at Google I.O. this year, where we announced Polymer 1.0. And I was in the audience. And I was thinking, but what if there isn't? And since I thought it's probably a safe assumption to make, but I'm not the only one with that question, I thought I'd use this opportunity in particular the Polymer Summit to write an element with you. Something that shows like a few little tricks, some design patterns that will make you write an element that integrates well with the rest of the elements that are already out there so that you will have a good app. So as I said, with Polymer 1.0, we also announced the catalog at Google I.O. By now, there's actually more catalogs out there that you can just find and have like collections of elements. But for us, we have these collections of collections, to be exact, that solve multiple use cases that you will encounter when you're writing your apps. So we have wrapped most of the client-side APIs. If you're looking for a server-side API, chances are a little bit slimmer, but they're steadily growing over time. And especially for Google APIs, we have basically elementized all of them. And I think elementized is a word now. We've gained, obviously, a lot of experience while writing these elements in terms of what kind of patterns they are. And we discovered a few practices, and that's what I want to share with you. However, I want to be clear that what I'm saying and what I'm going to be saying are patterns that are not untouchable just because we are Google. These are things that we've found to be working well. But Polymer 1.0 is still kind of new, so things will evolve and be trashed and maybe be deprecated at some point in terms of patterns. And the new ones will come up at some point. So here's an example of what we're going to look at today. This scenario is pretty clear. You have an API, but you don't have a specific element. So the question is, what you're going to do? So this could be like some third-party API. This could be the API of your very own startup, and you thought about wrapping this. And this is something you might be asking, why would I want to wrap the API in an element in the first place? And this is something where actually web components already shine because they give you the ability to turn something like an API which you would usually lose programmatically into something that you use declaratively. And that is a really powerful concept. It gives you a toolkit. It gives you a common vocabulary to talk about what you actually want to do and gives you the ability to be composable, something that Kevin already talked about very much. It also something that's really nice is that it gives you the ability to do refactoring because you're literally moving elements around, either from one element to another or just inside one element. So Polymer is really standing on the shoulders of giants. You're namely web components and all the other web standards that we're actually combining under the hood. So I hope I've convinced you that you do want to write an element for your API. Now the question is, how do you do that? The main goal usually is to hide the complexity but still make it available to the developer if he wants to. And how you do achieve that is usually by using two-way bindings excessively. Two-way bindings are a really powerful concept that we give to you inside Polymer. And I'm going to show you how this works. But even for APIs, we have elements to talk to in a generic way. We have seen before that there's an IronAJAX element, something that turns vanilla XHR request into a Polymer kind of thing. And we have even more of these kind of generic elements in the catalog. So before you start, always take a look at our and all the other catalogs if there's something in there that you want to combine into a new element because composing is really the main thing to do. So I thought for this talk, I would use a website that we all know and love and probably use every day, which is Reddit. And there is no element for that. I just said that actually. So we're going to build what you're seeing right now together. So this is straight up just off-the-shelf elements. This is a paper input. It's paper radio buttons. It's a HTML5 standard list. And we're just composing these into an app that will allow us to list the current entries in a certain subreddit. So everything is there except for one element. And that is how we actually get the data, our connection to the Reddit API. I will use Reddit's JSONP API for multiple reasons. Once, for once, it allows us to avoid the course issue. It forces me to stay read-only for this talk. Otherwise, this would not be a 20-minute talk. And also, we already saw IronAgeX before. And this will actually utilize another element from the catalog. So this will be the app. This will be the app that uses the element that we are going to write. It looks kind of overwhelming right now. But I hope at the end that this will kind of make a lot of sense to you. So don't try to read it just now. As I said, it's all off-the-shelf elements except for the Reddit API element, which is what we are going to focus on right now. So the use, it should be kind of obvious to you, I hope. It takes a subreddit as a string. And it takes a sorting as a string. So you can decide if you want to see the hot topics, the new topics, or the controversial ones. And via the post attribute, it spits out an array of the posts that are actually in the subreddit according to the sorting. That was usage. Now let's start implementing. As we've said before, and I think Rob said that, it is kind of weird to think about having elements in your code that don't render. But for API elements, it would actually be confusing if they did. So a rule of thumb is if you actually have an element for an API, don't put any visual content in there. Just have it as an element that you take a reference to, and that's it, no more. And you can see here a very slight version of composing. We are using another iron element inside our own. And this is the ironJSMP library element. This element is great because it makes ironJSMP weirdness into something that feels kind of all right, even though it's still JSONP. So for example, this element takes, via the library URL property or attribute, it actually takes the URL to load and takes care of generating a unique callback name for you. So you can even fire off multiple requests concurrently with that element and don't have to worry about these different requests interfering because each request will get its unique callback, which is really good. Also note that we are actually binding the library URL to a property called request URL. This is actually, I think, the most important property of our own element, but we're going to get to that in just a minute. Let's look at the other properties first because they're actually really simple. So the first one is the subreddit property. It's obviously a string. I'm using reflectToAttribute, but note that reflectToAttribute has to be used with care because what it does is it actually deserializes the actual value to the DOM and deserializes it if you're actually going to use it. So this can be really slow, especially if you do it often or if the value is actually huge if it's like a huge JSON object. So for example, I will not be using reflectToAttribute on the post property because that would make everything look ridiculous. Also in this particular instance, I like using reflectToAttribute because it gives you the ability to look at the current value in the DOM inspector of your browser. Also a reason why it would look really weird on post because that would be like a huge JSON string in the middle of your API inspector. But since we're writing an API element right now, it's safe to do reflectToAttribute because these API elements are usually only used once on a single page. Notify has been introduced multiple times before. This is just there. So we have it available for two-way binding. And as I said, two-way binding is what we are going to use a lot because it's really, really powerful. Sorting, exact same thing. Post is the first property that's actually a little bit different. First of all, it's obviously an array, not a string. So we are having a different type here. I also declared readOnly. As I said, this element is going to be readOnly. You will not be able to post something to read it by appending to the post attribute or something. And also, what's really interesting is that posts will, on the side, generate a setter function that is called underscoreSetPosts. So we can set the value, obviously, but from the outside, if you assign to the post property, it will actually raise an error and you know you will have done something wrong. I also added a default value just to make sure and notify again for the two-way bindings. There's actually a fourth property that I didn't talk about because it's not really important, but I did add it, which I call base URL. So technically, this Reddit API element is going to be able to talk to your private hosting of it if you have something like that. But the default value obviously uses the official API endpoint of the front page of the web that we all know. Let's get to request URL because this is where it's actually going to get interesting. Request URL is, as I said, bound to the library URL of our JSONP element. So it's supposed to have the value of the endpoint where the JSONP request is supposed to be sent to. And as you can see here, it's actually a computed property. So what that means is that we're declaring, or we're saying, use this function to actually calculate the value of this property. And these are the parameters that the value depends on. And then Polymer does something great. It takes care for us of the fact that whenever any of these properties change, it will automatically reevaluate this function. And the request URL property will assume the return value of that function. This is the function that is going to be called. It just effectively concatenates all these different attributes. It also appends the percent callback percent placeholder. That is a predefined placeholder of the JSONP element. And it will be replaced by the uniquely generated name for the callback. And what this means is whenever any of these attributes change, the URL will be recomputed. It will be immediately passed on to the JSONP element. And this will, in turn, mean that this request will immediately get fired off, and it will get new data. So we have just written an element that is completely event-driven without us ever touching the explicit event infrastructure. So whenever the user changes, like clicks on one of the radio buttons or changes to separate name, immediately data will get reloaded, and you will immediately see the new posts on the app that we have written. So as a last thing to look at is just the event handler new data that we are using just there. And that's actually pretty boring. The data that we get back from Reddit is huge. It's exhaustive, so I'm just mapping over the post and taking out the title and the link, because that's all we need. And then I'm using the previously mentioned set posts function to set the value of our read-only posts attribute. So let's get back to the app that I mentioned earlier. It's still kind of overwhelming, but now we know all the elements because everything else is off the shelf, as I said. So let's look at this step by step. So first of all, we have the paper input. We have introduced paper input before, and we know that we actually don't need to do the colon, colon trick that Kevin mentioned, and I'm doing it anyway for a simple reason because I'm not listening to the value changed event but to the change event, which is a DOM native event. I'm doing that because if I left that out, every key press would have emitted an event and our DOM would look like this. Every key press would fire off a JSONP event, and we don't want that. By rebinding this value to the change event, I'm effectively waiting for the user to click somewhere else outside the element, then the input field will emit, I have changed my value only once, and then we will fire off the JSONP request. So we will only have one request on the bottom line. The next element that we have is our radio group. It's straight up a radio group with radio buttons. I actually just wanted to excuse to use emoji in my slides. It's just one of three sortings, pretty straight up. And lastly, and this is probably the most interesting part of this front end part of the app, is a DOM repeat. We are using the right API to give us the posts two-way binding and passing that in as a one-way binding to the DOM repeat. So we are using this to render all of the titles of the posts in the current subreddit and we'll link to the posts by using an anchor tag. And now suddenly this should not look as complicated anymore. You should actually kind of see what's going on. It's kind of straightforward. So to summarize, we actually just built an app that reacts immediately to user changes without having to do any bookkeeping of our own. And this is one of the powers of two-way bindings, no extra wiring required. So as a last thing, I wanted to go to the Platinum Elements. Matt just talked about a lot of them, but he talked about the usage. When I looked at them, especially at the server-searcher elements, I was kind of amazed. If you know the browser-level API of server-searcher, you know that it can get kind of weird. And then I looked at the Platinum Server-searcher elements and it was just like magic voodoo. I did not understand how it would be possible to wrap this weird API that is used outside your main thread into an HTML declarative-style thing that is in the main JavaScript thread. And once I looked into the implementation, I actually realized it's a really, really nice pattern to hide complexity, but still give you the ability to go through the veils and actually do everything you need to do if you wanted to. So this is the server-searcher register element. It registers a server-searcher for you, pretty straightforward. You can hook up to events to get notifications about when the server-searcher has been successfully installed or when it's been updated or when it's failed so you can react appropriately. You can influence the registering process itself, but you can't really do anything else with the register element alone. You can say, please cache these files or please call this JavaScript function when a certain request is being fired. So as an example, I used import script and fetch. These are two elements that you can use inside the register element. You can put them as children to the register element and basically say import the script for me and execute it inside the server-searcher and then you can say, please call this handler whenever a request from the web page is being made matching this pattern. And this handler would have been defined in one of these scripts that you imported earlier with the import script tag. You can also already see a little bit of synergy there. So the question is, how does this work? How does this communicate with the service worker and that you can actually kind of modify this? It's complicated, but that's the point, right? You re-hide the complexity for you. So I'm gonna explain to you now how it works and it's gonna be a little bit unwieldy, but in the end, it's just about this pattern of using children elements. So the first thing that this register element does is it iterates over its own children. So it looks on all its children and checks if the element has underscore get parameters function. And if that's the case, it's gonna call that function and expect this function to return a promise and it collects all these promises in an array. In the next step, it's gonna wait for all these promises to resolve, expects each promise to resolve to an object and then merge these objects together into a huge object. This object in the end will kind of be a description of what you want the service worker to do in adjacent object notation, so to speak. This object in the next step will then be URL encoded in a stable matter and then used as a query part on the navigator.serviceworker.register call when calling a service worker script that we provide from the SW toolbox that Google published a while ago. In case I lost you, that's fine, but that's kind of the point. This is really complex. The way we try to shove data from the main site to the service worker site, we have to jump through a lot of hoops to make that working, but you don't have to worry about that because it's all encapsulated in both the register element and in the children element that you can arrange inside and use multiple times. So you're actually really just declaring what the service worker is supposed to do. And if you ever find yourself that you have to write something really complex and you wanna write an element, try to break individual subparts into sub-elements that you can use inside, which is a really nice parent to actually make it reasonable to you and can be able to give your team maybe a way to talk about this without going nuts. Also, to be honest, the code on the slides right now is already simplified by me. The code is even more complicated in the repo because we have a few corner cases we have to catch. So in any case, if you're interested, I encourage you to actually look at the code because it's really, really good. And I have a few more links for you that give, I think, a really good introduction on how to write elements, that you just look at the code and see what they're doing. They're usually very readable and they have been field tested so you know that they will work. And just to make something clear, this is really just the tip of the iceberg. Polymer 1.0 or Polymer 1.1 is still kind of new. We know about elements. We don't know that much about apps. Things are still changing and evolving. There will be new parents coming up. They're probably gonna be better than something that we're doing right now. So jump in and let us know how you're solving problems we're really interested to see. If you have questions, hit me up on Twitter. I'll be around, I will be around, especially in the Colab area, so swing by there and thank you for your attention.