 Hey there, Polycasters. Rob here. Many of you have written in and asked for an episode on the Iron AJAX element. There's a lot of questions around this element, like when to use it and is it bad to mix your behavior with markup like that. But in fact, Iron AJAX is one of the most useful elements you can have in your toolbox. However, its utility only becomes apparent when you combine it with data blindings. Anyway, today on Polycasters, I'm going to show you the power of working with AJAX using nothing but HTML. Let's check it out. Okay, so today we're going to create an element that fetches GitHub issues and we're going to use Iron AJAX to do that. Now I'm also going to use the yeoman generator to scaffold out my element, but if you don't want to use yeoman, you could use the seed element project, which I will link to down in the show notes. That will do the exact same thing as yeoman. Yeoman just goes a step further and it renames all the files for me, which is pretty convenient. So from my command line, I'll type yo-polymer seed g-h issues to generate my element. And once that's generated, I can run polyserve, which is our little local server, and that'll let me preview the element as I'm developing it. And you'll see here that it generates this URL that I can use to actually go look at my element's documentation. So using the seed element, it actually generates docs for us, which is pretty cool. It also has this demo link here, which we can click on, and that is going to show us sort of a demo of the boilerplate element that it has created. So this is all just stuff that it has sort of stepped out, and we're going to replace all this in just a second. Now, I mentioned we're going to use the GitHub API to fetch issues. So going and looking at the API docs, we can go down to the issues section. And you'll see here that working with the GitHub API is pretty simple. We just use get request to fetch the issues for either all the issues that are owned by a user or all the issues in a given organization. In our case, what we're going to do is we're going to fetch all the issues for a particular repository. So to do that, we're going to need to install IronAgeX. We'll go back to our terminal. We'll split the pains, and we will bower install IronAgeX, passing the save flag so it gets written to our element's bower.json file. Now that that is all good, we can go look at the element that was stubbed out for us by Yellman. So this is ghissues.html. And if you browse around here, you'll see there's a lot of boilerplate markup that it stubbed out just as an example for what an element could look like. We'll ignore that for a second and just go ahead and import IronAgeX as we know we're going to want to use that. And then I'll update my element's description. So I'm going to say this is an element for fetching issues from GitHub. And then I can go through and delete all of this extra markup that's inside of here. So again, I don't really need any of this. It's just sort of an example markup in case you haven't written an element before. It's good to read through just to see what's possible. But I want to strip it down to where I just have this sort of very bare skeleton. Next, I'm going to drop the IronAgeX tag inside of my template. And I'm going to configure it with a few attributes here. So this auto attribute tells IronAgeX to just automatically fetch data anytime it has a valid URL. It's just going to go and get some data. This URL attribute, as the name implies, is going to be where we go and get our data from. When that data comes back, we're going to need to handle it as something. So here we're saying handle it as JSON. I believe it also supports XML. And you could also tell it to fetch things as document. So for instance, if you are fetching an HTML file, you could say, hey, when that comes back, I want to treat it as a document. And then it also fires events. So there's a response event, which we could listen to and we could have a handler that works with that. But instead of writing a bunch of JavaScript to handle the response that comes back, let's just go ahead and give it a URL. So I'm going to tell it to look at rob.syn slash chart elements. That's the repo where we'll pull our data from. And I'm going to tell it to, instead of handling that in JavaScript, we'll just take the data that came back, which is represented as this last response property. And we'll create a scope variable for that called response. Now, let's think about what's happened here for just a second. I've got this one tag and it basically represents GitHub. This is like a representation of the GitHub API. I've configured it by saying this is where I'd like you to get data from. And then I've basically used a data binding to create sort of a declarative data provider. So I don't really know the mechanics of how it is going and getting my data. Nor do I care, like the implementation of how it's actually going and getting the data I don't actually care about. Instead, all I care about is that it goes here and it this data. And with this data binding, and because it's nice and declarative, I can now hook onto it with different DOM nodes and they will stay in sync with data. So this has removed the need for me to write a lot of JavaScript in my element. Normally, I'd have to handle that response, pick it apart, go find the different DOM nodes that I want to update with the new data. Here, we're just saying, hey, I've got this nice declarative data provider, and when that data comes back, all my DOM nodes that bind to it will stay nice and in sync. So pretty cool approach there. This is a representation of the response that we're going to get back from GitHub. You can see it's an array of objects. And the properties that I care about are this one right here called HTML URL. So this is the actual URL to the GitHub issue. And then I also care about the title. So this is what we'll display in our list of issues. So let's go back to our template here. And because we've got this nice declarative data provider now, let's generate some DOM for it to link up to. So I'll create a template with a DOM repeat template. And I'm going to give it an items attribute. And we're going to link these two together. So you can see this little linkage that we've created here. We're saying the items should be linked to that response. So now that these are combined, this template is going to try to iterate over that collection, that array of objects. So we can drop a div with an anchor inside of here. And we can bind to, for every single item, can bind to its HTML URL and its title. So now we're just generating this list of anchor tags based on that response. And this is pretty cool because, again, I didn't have to write a bunch of JavaScript to handle all of this. I've just created this little linkage here. I've got this nice little declarative data provider. And I'm just generating DOM based on the data that it returns. So let's go look at the demo file that I showed you earlier as part of our documentation. We're going to clean this up a little bit so that we can preview our tag. Again, Yeoman generates a bunch of boilerplate. And it's cool if you haven't seen it before. But in our case, we're just going to delete it. We'll drop in the ghissus tag. I'll bump this up a little bit so you can kind of see a bit better. And yeah, let's just preview this thing in Chrome. So we'll click on our demo button. And we'll see these are the two issues that come back from that repo. And click on one and open it in a new tab to verify that came from RobDots and chart elements. So OK, yeah, we've got our very basic element working. It's fetching data from the GitHub API. And so far, we haven't really written any JavaScript whatsoever. We're just fetching data. We're generating DOM based on that data. And that's kind of a cool flow. But let's see if we can push this a little bit further and make this thing a bit more configurable. So if we go back and we look at our elements definition, you can see that I've hard coded the path here, which kind of a bummer, right? I want anybody to be able to use this tag. And so what I can do is I can take the owner and I can take the repo name. And I can make these configurable properties of this element. So let's go down to the properties object and stub out two properties, one called owner. And we're going to say that by default, it has the value of Polymer. Sure, why not? And we're also going to make it two-way bindable. So we'll say it fires change events when it changes. So we're saying it's notified true. And we'll also create another property called repo. We'll also set that to Polymer. And this will also be a two-way bindable. And lastly, I'm going to create a computed property called URL. And what it's going to do is it's going to compute the values of owner and repo. So either of these changes, it is going to recompute the URL where we're fetching from in GitHub. And we're going to stub out this method here for compute URL. And we'll say, hey, when we get owner and repo, what we should do is we should take that hard coded URL that we were working with before. So let's copy this. We'll drop it into an array. And we'll replace where it has the owner and repo right here. We'll just replace those with these two values that are being passed in. So as someone's configuring our tag, they're passing in an owner and repo, that's going to update this URL. So it passes in. And then we're just going to join the whole string with slashes to turn it back into a URL. And we'll say, hey, this is what Iron Age Act should bind to, this configurable computed URL now. So let's switch back over to Chrome. Now we've got this set up. And we can go look at our demo. You'll see now we're seeing all the issues from the Polymer repo. We can actually open one of these and see, yep, organizations, Polymer repo. But let's configure it a little bit more. So now we can go in and we can pass whatever owner and repo we want because we have these properties. And we can pass them values as attributes. So let's look at Polymer Elements, PaperInput, refresh the page here. Now we're looking at issues from PaperInput. So this is pretty cool. Now anybody can use this tag to pull issues from GitHub, which is pretty awesome, right? But I think we can actually take this a bit further. So just for funsies, let's take the demo that we're working on here and wrap it in an auto-binding template. And this is going to let us use data bindings inside the space without creating our own tag. And I'm just going to take owner and repo and make them bindable. So I'll create two text inputs. These are just native text inputs. So one is going to bind to owner, and one is going to be bound to this repo variable. And because we're creating data bindings on native elements, notice that I'm using this sort of special double colon syntax. So this is sort of how Polymer allows you to set up data bindings on native tags. Native tags, they fire their own events when something has updated. In the case of the input element, anytime you have finished typing some text inside of it, it is going to fire a change event. And so we're saying, hey, when you hear the change event, update the owner binding, right? Same with the repo binding. So now I can go and I can replace these with those same scope variables, owner and repo. And now if we switch over to Chrome, you'll see that at the bottom I've got these two text inputs. They are initially receiving the values that the GitHub issues element put out. So owner and repo are initially Polymer. But we can change these. So we can say, hey, this should be Polymer elements, and this should be like IronAgeX. And watch here, all of the issues update. And that's because we have that auto attribute on our IronAgeX element. So we've given it some new values. It recomputed the URL. It told IronAgeX to go fetch that new data. And that updated our DOM for us. And again, we didn't need to write a bunch of JavaScript to manage all of this flow. And that's, again, sort of the power of a nice declarative data provider like IronAgeX, which is pretty cool. You can actually, yeah, you can open one of these up too and you can see that verify that it's actually pulling from Polymer elements IronAgeX. Now, another thing you may want to do when you're working with AgeX is pass along parameters. So you might be like, hey, I want to go to foo.com, dollar sign, or sorry, question mark, q equals like some value or something like that. You can pass along parameters as you're working with these URLs. And if we look at the GitHub API, you can see that there's a few parameters we could pass. One of them is state. So we could say, hey, give me all of the issues for this repo and maybe I want just the closed ones or just the open ones. So that's one parameter that we can use. Another one is this down here for page. So it's a little hard to see. But we can actually paginate our URLs as well. So we can be like, hey, I want page three of all of the closed issues, stuff like that. So let's go and let's add that to our element as well. We'll go back to our markup here and we can give IronAgeX this params attribute. And you could give it this JSON encoded object. And that could be how you pass along parameters. So we could say, state, I want all the open issues. And I want it to be page number one. But again, where's the fun in that? Let's make this configurable. So much like we did with the URL, we can replace params with a computed value. So I'm going to create a binding for options. That's what we'll call our computed value. And we'll say that we want to create state and page properties. And we will create a new computed value called options, which will just compute state and page. So anytime there's change, it is going to return a JSON object with whatever the state is and whatever the page is. So it's kind of a weird example, but you can see that it demonstrates how parameters work. So now we can go back and we can create bindings for state and page instead of our demo. And just like we did with owner and repo, I will create input fields for these as well. So now when we swap back, if you look, you can see, again, it's initially bound to Polymer Polymer. It defaults to all of the open issues and it defaults to page one. And so let's change that. Let's say, hey, I want to see the closed issues in Polymer. That updates. I want to see page three of the closed issues in Polymer. That updates. And I want to look at page three of the closed issues from maybe paper input. And that works as well. And again, we can go back and we can open one of these. I'm going to verify it's a closed issue coming from paper input. So pretty cool. We've created now this pretty robust little element. It does a lot of really fancy stuff. It's entirely configurable. The user can just go in and live edit it. And they're getting all this data back. It's updating the DOM. And we're not having to write a bunch of JavaScript to manipulate the DOM in any way, which is rad. So when should you use IronAgeX? Well, that really depends on context. If you're in a situation where you've got like 30 IronAgeX tags sprinkled throughout your element, then, yeah, maybe consider doing it with JavaScript instead. But if you only need a simple data provider without a whole lot of fuss, then perhaps IronAgeX is a good fit for your application. We talked a lot about IronAgeX today, but I've actually only barely scratched the surface. And so if you go over to the catalog, you can see that there's this IronElement section. You can go there and check out the docs for IronAgeX. And there's a ton of things that this does. It does the full breadth of what you can do in AgeX. So you can add body to it. You could change the method to post or put. You can see all the various methods that the element supports, the events that it fires, and so on. So definitely go read through the docs of IronAgeX, because there's a lot of power in this one little tag. Also, a little bit of shameless promotion here. We just finished doing a big event in Amsterdam, which we're calling our Polymer Summit. I will here, I'll draw a little link here so you can click on that annotation to go to the actual website. It's a full day of talks and code labs for you to check out to learn all things Polymer. So you can go check out our playlist over here on the Chrome developers channel and see all of our videos. You can also go to our code labs, and maybe click this as an annotation, go check out all of our code labs. And again, there's tons of stuff for you to play with if you're just getting started with Polymer, or even if you're a bit of a Polymer pro, there's probably something in here for you. So if you miss the Polymer Summit, go check that out. That's it for today, folks. If you've enjoyed this episode, consider clicking that little subscribe button down there at the bottom. Also, if you have questions for me, you can leave them in the comments, or you can ping me on a social network of your choosing at hashtag askpolymer. As always, thank you so much for watching, and I'll see you next time.